web service security lecturer: tr ầ n th ị qu ế nguy ệ t students: tr ầ n trúc giang ...

WEB SERVICE SECURITY

Lecturer: Trần Thị Quế NguyệtStudents:Trần Trúc GiangNguyễn Thị Hòa Bình

1

OUTLINE

Web Service Introduction XACML SAML Shibboleth

2

WEB SERVICE INTRODUCTION

3

WEB SERVICE INTRODUCTION

Service-Oriented architecture (SOA) Web service definition Web Service Description Language (WSDL) Simple Object Access Protocol (SOAP) Universal Description, Discovery and

Integration (UDDI)

4

SERVICE-ORIENTED ARCHITECTURE (SOA)

W3school.com: SOA is a mechanism that enables organizations

to facilitate communication between the systems running on multiple platforms

SOA is a collection of well-defined services, each individual service can be modified independently of other services to help respond to the ever-evolving market conditions of a business

SOA presents the big picture of what you can do with web services

5

SOA’S COMPONENTS

6

WHAT ARE WEB SERVICES?

W3C’s Definition: a software system designed to support interoperable machine-to-machine interaction over a network.

Web services:application componentscommunicate using open protocolsself-contained and self-describingcan be discovered using UDDIcan be used by other applicationsXML is the basis for Web services

7

WEB SERVICES PLATFORM ELEMENTS SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and

Integration) WSDL (Web Services Description Language)

8

SOAP (SIMPLE OBJECT ACCESS PROTOCOL)

SOAP is an XML-based protocol to let applications exchange information over HTTP.

Or more simple: SOAP is a protocol for accessing a Web Service.

9

WSDL (WEB SERVICES DESCRIPTION LANGUAGE)

WSDL is an XML-based language for locating and describing Web services.

WSDL file:

<?xml version="1.0" encoding="utf-8" ?>- <definitions xmlns:s="http://www.w3.org/2001/XMLSchema“..... xmlns="http://schemas.xmlsoap.org/wsdl/">+ <types>+ <message name=“addSoapIn">+ <message name=“addSoapOut">+ <portType name=“TestWSSoap">+ <binding name=“TestWSSoap" type=“TestWSSoap">+ <service name="TestWS"></definitions> 10

UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION)

UDDI is a directory service where companies can register and search for Web services

11

SECURITY REQUIREMENTS FOR SOAP-BASED WEB SERVICES

13


14


15

XML SECURITY FOR WEB SERVICES The XML Signature specification is a joint effort of W3C

and IETF. It aims to provide data integrity and authentication (both message and signer authentication) features, wrapped inside XML format.

W3C's XML Encryption specification addresses the issue of data confidentiality using encryption techniques. Encrypted data is wrapped inside XML tags defined by the XML Encryption specification.

WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message.

16

XML SECURITY FOR WEB SERVICES

Security Assertion Markup Language (SAML) eXtensible Access Control Markup Language

(XACML)

17

OUTLINE

Web Service Introduction XACML SAML Shibboleth

18

THE EXTENSIBLE ACCESS CONTROL MARKUP

LANGUAGE (XACML)

19

XACML

The eXtensible Access Control Markup Language (XACML) is an XML vocabulary for expressing access control policies.

Access control consists of deciding if a requested resource access should be allowed and enforcing that decision.

Access control policies are the criteria for making access control decisions.

The XACML core specification defines the syntax of the language and the rules for evaluating policies.

20

PREFERRED TERMS

21

PREFERRED TERMS

22

PREFERRED TERMS

23

Resource: Data, service or system component.

Subject: An actor whose attributes may be referenced by a predicate.

Action An operation on a resource. Four kinds of actions: read, write, create, and

delete. Environment: The set of attributes that are

relevant to an authorization decision and are independent of a particular subject, resource or action.

PREFERRED TERMS

Attribute: Characteristic of a subject, resource, action or environment that may be referenced in a predicate or target.

Context: The canonical representation of a decision request and an authorization decision.

Context handler: The system entity that converts decision requests in the native request format to the XACML canonical form and converts authorization decisions in the XACML canonical form to the native response format. 24

DATA-FLOW DIAGRAM

25

DATA-FLOW DIAGRAM

26

DATA-FLOW DIAGRAM

27

DATA-FLOW DIAGRAM

28

DATA-FLOW DIAGRAM

29

DATA-FLOW DIAGRAM

30

DATA-FLOW DIAGRAM

31

DATA-FLOW DIAGRAM

32

DATA-FLOW DIAGRAM

33

DATA-FLOW DIAGRAM

34

DATA-FLOW DIAGRAM

35

DATA-FLOW DIAGRAM

36

DATA-FLOW DIAGRAM

37

DATA-FLOW DIAGRAM

38

DATA-FLOW DIAGRAM

39

XACML - ADVANTAGES

According to Sun, XACML has a number of advantages over other access-control policy languages: One standard access control policy language can

replace dozens of application-specific languages Administrators save time and money because

they don't need to rewrite their policies in many different languages

Developers save time and money because they don't have to invent new policy languages and write code to support them. They can reuse existing code

40

XACML - ADVANTAGES

Good tools for writing and managing XACML policies will be developed, since they can be used with many applications

XACML is flexible enough to accommodate most access control policy needs and extensible so that new requirements can be supported.

One XACML policy can cover many resources. This helps avoid inconsistent policies on different resources.

XACML allows one policy to refer to another. This is important for large organizations. For instance, a site-specific policy may refer to a company-wide policy and a country-specific policy.

41

XACML - LIMITATIONS

XACML is verbose and complex in some ways.

Interactions involving PAP, PIP, etc., are not standardized.

Policy administration, policy versioning, etc., are not standardized.

42

SAMLSecurity Assertions Markup Language 43

SINGLE SIGN-ON (SSO)

SSO is a property of access control of multiple, related, but independent software systems.

With this property a user logs in once gains access to all systems without being

prompted to log in again at each of them.

44

WHY CHOOSE SINGLE SIGN-ON?

User needs to remember multiple usernames and passwords to access different applications on a network.

This poses a huge cost for the administration and support departments.

Authentication is a horizontal requirement across multiple applications, platforms, and infrastructures.

46

WHY CHOOSE SINGLE SIGN-ON?

The objective of SSO Allow users access to all applications from one

logon. Provide a unified mechanism to manage the

authentication of users and implement business rules determining user access to applications and data.

Benefits include the following: Improved user productivity. Improved developer productivity. Simplified administration.

47

IMPLEMENTING SSO REQUIRES

Identity Provider (IdP): The system, or administrative domain, that asserts information about a subject.

Service Provider (SP): The system, or administrative domain, that relies on information supplied to it by the Identity Provider. It is up to the Service Provider as to whether it trusts the assertions provided to it.

Exchanges of authentication and authorization data between an IdP and an SP are effected by means of an XML standard called the Security Assertion Markup Language (SAML).

48

SAML - INTRODUCTION

The Security Assertion Markup Language (SAML) standard defines a framework for exchanging security information between online business partners.

As stated in the SSTC charter, the purpose of the Technical Committee is: to define, enhance, and maintain a standard

XML-based framework for creating and exchanging authentication and

authorization information.

49

SAML – USE CASE

There are four “drivers” behind the creation of the SAML standard: Limitations of Browser cookies SSO Interoperability Web Services Federation

50

SINGLE SIGN-ON USE CASE

51

FEDERATION USE CASE

52

SAML COMPONENTS Assertions: SAML allows for one party to assert

characteristics and attributes of an entity. Protocols: SAML defines a number of

request/response protocols. The protocol is encoded in an XML schema as a set of request-response pairs.

Bindings: This details exactly how the SAML protocol maps onto the transport protocols. For instance, the SAML specification provides a binding of how SAML request/responses are carried with SOAP exchange messages.

Profiles: The core of the SAML specification defines how the SAML requests and responses are transported, however, a number of use cases have been developed that require the formulation of Profiles that define how the SAML assertions, protocols and bindings are combined.

53

SAML COMPONENTS

54

SAML - STRUCTURE

Assertions: An assertion consists of one or more statements.

For SSO, typically a SAML assertion will contain a single authentication statement a single attribute statement.

55

SAML - STRUCTURE

56

SAML - STRUCTURE

SOAP over HTTP Binding: In environments where the two communicating end points are SOAP enabled, then the SOAP over HTTP binding can be used to exchange SAML request/query and response protocol messages.

57

SAML - STRUCTURE

58

USE OF SAML IN OTHER FRAMEWORKS - XACML

SAML Assertions provide a means to distribute security-related information that may be used for a number of purposes. One of the most important of these purposes is as input to Access Control decisions.

The eXtensible Access Control Markup Language (XACML) is an OASIS Standard that defines the syntax and semantics of a language for expressing and evaluating access control policies.

The work to define XACML was started slightly after SAML began. 59

PREFERRED TERMS

60

USE OF SAML IN OTHER FRAMEWORKS -XACML Using SAML and XACML in combination would typically

involve the following steps.1. An XACML Policy Enforcement Point (PEP) receives a request to access some resource.2. The PEP obtains SAML Assertions containing information about the parties to the request, such as the requester, the receiver (if different) or intermediaries. These Assertions might accompany the request or be obtained directly from a SAML Authority, depending on the SAML profile used.3. The PEP obtains other information relevant to the request, such as time, date, location, and properties of the resource.4. The PEP presents all the information to a Policy Decision Point (PDP) to decide if the access should be allowed.5. The PDP obtains all the policies relevant to the request and evaluates them, combining conflicting results if necessary.6. The PDP informs the PEP of the decision result.7. The PEP enforces the decision, by either allowing the requested access or indicating that access is not allowed.

61

USE OF SAML IN OTHER FRAMEWORKS -XACML

62


63


64


65


66


67


68


69

SHIBBOLETH

70

INTRODUCTIONMany people

Many resources

Many locations

federated identity

federations

hard to manage access to resources

authenticate provide user attributes

SSO systemIdentity Providers Service Providers

form federations

71

DEFINITION Shibboleth is an Internet2

Middleware Initiative project that has created an architecture and open-source implementation for federated identity-based authentication and authorization infrastructure based on Security Assertion Markup Language (SAML). Federated identity allows for information about users in one security domain to be provided to other organizations in a federation.

This allows for cross-domain SSO and removes the need for content providers to maintain usernames and passwords. Identity providers (IdPs) supply user information service providers (SPs) consume this information and

get access to secure content.

72

HOW IT WORKS?• Interrealm Attribute-based Authorization for Web

Services• An initiative to develop

• An architecture• Policy framework• Practical technologies to support inter-institutional sharing

of resources• Based on a federated administration trust framework.• Provides the secure exchange of interoperable attributes

in access control decisions.• Controlled dissemination of attribute information, based

on administrative defaults and user preferences. • Shifts the model from passive privacy towards active

privacy.• Developed with vendor participation - IBM/Tivoli.• Standards Alignment - OASIS/SAML.• Open solution.

73

FEDERATION

Group of institutions agree

set of policies - practices - standards For

Authentication security of components/ exchange use

population of user attributes Trust model to work between institutionsSPs will accept attributes from any IdP in

the Federation74

FEDERATED ADMINISTRATION

Origin Site•Must have joined AC•Create default ARP•Identification and registration of users•Managing attributes•Authenticating users prior to resource access

Target Resource Manager

•Must have joined the appropriate communities •Manage policies governing access to the resource

Leverage local authentication mechanisms

Browser User•Need to know the name user’s origin domain•Create specific attribute release policies

75

TECHNICAL COMPONENTS

76

COMPONENTS

77

1.In a web browser, the user attempts to access a resource protected by the SP.

2.The user is not authenticated so the user is redirected to the WAYF service.

3.The WAYF service asks the user to choose an institution (IdP) to authenticate at.

4. The user chooses an institution (IdP).5.The user is redirected to the Handle Service of the chosen IdP.

6.The Handle Service works with the local SSO system to ask the user to authenticate.

7. The user supplies credentials to authenticate (e.g. username and password).

If the credentials are valid the Handle Service generates a handle for the user and supplies it to the ACS of the SP.

The ACS validates the handle, creates a session and transfers the handle to the AR.

10.The AR request attributes from the AA of the IdP using the handle.

11.The AR request attributes from the AA supplies attributes in the form of assertions.

12.The attributes are used by the SP to determine whether to permit access to the resource.

13. If permission has been granted the user is able to access the resource.

Authentication Phase

COMPONENTS

Second Access - Authenticated

Target Web

Server

Origin Site Target Site

Browser

First Access - Unauthenticated

Web Login Server Redirect User to Campus for AuthnPass content if user is allowed

Aut

hent

icat

ion

AttributeServer

Pass Privileges for Authz Decision

Ask For Privileges

Authorization Phase

WAYFHS

Success!

78

IDENTITY PROVIDER(IDP)

IdP allows the user to authenticate stores information about the user as attributes.

When a user authenticates, the IdP creates a privacy-preserving handle for the user which can be used by service providers to request user attributes.

79

SERVICE PROVIDER

Service Provider Y N

Acts as a guardian of a Web resource

80

INDEXICAL REFERENCE ESTABLISHER(SHIRE)

SP responsible for context/session establishment. Session establishment will commonly rely on

traditional techniques. With no session in place, the SHIRE knows

nothing about the user, so must Ask directly (SHIRE==WAYF) Redirect the user to a location that will ask on its

behalf (SHIRE!=WAYF) The SHIRE accepts and validates an assertion

from a HS. Associates the incoming handle with the session

it creates. Passes control to the SHAR. 81

WHERE ARE YOU FROM?

The WAYF service provides the user with a list of institutions (IdPs) and allows them to choose at which one they wish to authenticate.

Then, the WAYF redirects the user to the chosen IdP.

82

HANDLE SERVER Works with AA and local Web ISO system

(authentication) to associate a query handle with an authenticated browser user and generate a signed assertion.

Performs its work in response to an Attribute Query HR.

Triggers local campus authentication system. Generates a Handle. Remembers mapping from Handle to specific

user. Sends Assertion with Handle to SHIRE.

83

ATTRIBUTE REQUESTER

Attribute: authenticate stores information about the user.

A SHAR makes attribute requests using the handle given it by the SHIRE.

Upon receiving a response (AQR): Authenticates the response

The attribute assertion contains the name of the origin site.

Extracts the attributes. Checks attribute acceptance.

84

ATTRIBUTE AUTHORITY Receives Attribute Query Messages

(AQM) from SHAR Returns Attribute Response Message (ARM).

• Finds ARPs matching target.• Determines which attributes and values to

release. Provides UI for specification and

management of Attribute Release Policies (ARPs).

Works with institutional directories and databases to aggregate and export attributes in a controlled fashion.

85

MANAGEMENT OF ATTRIBUTE RELEASE POLICIES(ARP)

The AA provides ARP management tools/interfaces.Different ARPs for different targets.Each ARP Specifies: attributes - values. Institutional ARPs (default)

Administrative default policies / attributes.Site can force include and exclude.

User ARPs managed via MyAA web interface.Release set determined by combining Default /

User ARP for the specified resource. 86

RESOURCE MANAGER

Accepts Attributes from the SHAR Compares supplied Attributes against

Policy associated with requested resource Grants/Denies access

87

ADVANTAGE End User Authentication

Unified authentication mechanism, more scalable, less integration work

Access Control Ability to implement fine-grained access control by attributes,

control usage costs. Leading Edge

Ability to market yourself as being at the fore front of compelling new technology adoption.

ROI - Vendor The incremental cost of adding new customers is relatively minimal.

ROI - Customer support inter-institutional applications, leveraging something

already in place. A matter of managing attributes/The installation is relatively easy.

Joint Procurement: Opportunity to offer joint procurement services Providing economies of scale 88

REFERENCES http://www.w3schools.com/ http://www.xml.com/pub/a/ws/2003/03/04/security.html?page=2 http://xml.coverpages.org/xacml.html http://www.oasis-open.org/committees/tc_home.php?wg_abbrev

=xacml#INTEROPS http://sunxacml.sourceforge.net/ http://en.wikipedia.org/wiki/Security_Assertion_Markup_Languag

e http://www.oasis-open.org/committees/tc_home.php?wg_abbrev

=wss http://www.oasis-open.org/committees/download.php/3412/sstc-

saml-diff-1.1-draft-01.pdf http://www.oasis-open.org/committees/security http://projects.staffs.ac.uk/suniwe/project/shibboleth.html http://middleware.internet2.edu/shibboleth http://www.internet2.edu/members/html/

intellectualproperty.html 89

Q&A

90

web service security lecturer: tr ầ n th ị qu ế nguy ệ t students: tr ầ n trúc giang ...

Documents