Web Services and Security

1. Web Services and Security

2. Introduction: Web Services and Security • When Web Services-based exchanges branch out beyond an organization’s firewall and span across organizations, security becomes a much larger factor than it is for exchanges that are behind the firewall • Security involves multiple requirements, such as: • Integrity: Ensuring that messages have not been tampered with en route or otherwise • Non-Repudiation: Ensuring that a party to a contract or communication cannot deny the authenticity of their signature or the fact that they originated a message • Authentication/Identity Management: Requiring proof of identity in a Web-based transaction • Authorization: Controlling access privileges to resources • Confidentiality: Protecting information from interception during transmission, and potentially afterward

3. Introduction: Web Services and Security (cont’d) • We will cover:

4. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

5. The OASIS Web Services Security specification defines a standard mechanism for representing security information in SOAP headers • The initial set of Web Services Security specifications completed OASIS Public Review in October 2003 • Updates have been made, and the updated versions are now OASIS Committee Approved Specifications • OASIS Call For Vote is due March 31, 2004, at which time Web Services Security may become an OASIS standard • The WS-Security specification was created as part of the Global XML Web Services Architecture (GXA) framework • It was originally authored by Microsoft, IBM, and Verisign and was released in October 2001 • Submitted to OASIS in June 2002 • Security information can be username/password, X.509 certificate, Kerberos ticket (future), SAML assertion (future), XrML token (future), biometric information (future), etc.

6. An XML Example • Example - Direct Trust Using Username/Password: <?xml version="1.0" encoding="utf-8"?> <S:Envelope …namespace declarations go here…> <S:Header> <wsse:Security> <wsse:UsernameToken wsu:Id="MyID"> <wsse:Username>Zoe</wsse:Username> <wsse:Password>…</wsse:Password> <wsse:Nonce>FKJh...</wsse:Nonce> <wsu:Created>2001-10-13T09:00:00Z</wsu:Created> </wsse:UsernameToken> …………… </wsse:Security> </S:Header> <S:Body wsu:Id="MsgBody"> …………… </S:Body> </S:Envelope> • Standard <Security> SOAP header, which contains the Username and Password

7. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

8. The OASIS Security Assertion Markup Language (SAML) defines an XML-based framework for exchanging security information • SAML Version 1.1 is an OASIS Standard as of September 2003 • Version 2.0 in process, with final Committee Drafts and OASIS Standard balloting by second quarter 2004 • SAML expresses security information in the form of assertions about subjects • An assertion is a declaration of certain facts, such as “John Smith was granted update privileges to database X at time Y” • A subject is an entity (either human or computer) that has an identity in some security domain • SAML can also be used to secure Web Services-based exchanges by authenticating requestors to Web Services, and Web Services to other Web Services

9. The SAML Domain Model describes mechanisms by which clients can request and receive assertions from “SAML Authorities” • Source: SAML Version 1.1 Specification

10. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

11. The Liberty Alliance Project is an initiative comprised of 160 organizations that defines specifications for federated network identity and single sign-on • Members include: American Express, Hewlett Packard, RSA Security, Sun Microsystems, and America Online,the U.S. Department of Defense and the U.S. General Services Administration (GSA) • The vision of the Liberty Alliance is to enablea networked world in which individuals and businesses can more easily conduct transactions while protecting the privacy and security of vital identity information • The Liberty architecture consists of a multi-level layered specification set based on open standards including SAML and SOAP • Support for authentication of Web Services and the definition of identity-related services are also included through the Web Services Framework (WSF) • Phase 2 specifications finalized in November 2003 • Six new global alliances were announced on March 19, 2004, plus the addition of Intel to the Liberty Alliance Management Board

12. The Liberty Alliance’s Federated Network Identity model defines enterprise and consumer “circles of trust” • A circle of trust is a federation of service providers and identity providers that have business relationships based on Liberty architecture • Source: Liberty Alliance Architecture Overview Version 1.1 Specification

13. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

14. WS-Federation builds on WS-Trust to define mechanisms for federated network identity and security • The WS-Federation specification was created as part of the Global XML Web Services Architecture (GXA) framework • It was authored by Microsoft, IBM, Verisign, BEA, and RSA Security and was released in July 2003 • WS-Federation covers many of the same aspects that Liberty Alliance and SAML cover (SAML Version 2.0) • May potentially merge with one of these specifications • WS-Federation allows a set of organizations to establish a single, virtual security domain • Example: A travel agent, an airline and a hotel chain may set up such a federation • An end-user that "logs into" any member of the federation has effectively logged into all of the members

15. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

16. WS-Trust defines a mechanism for setting up and verifying trust relationships that span domains • The WS-Trust specification was created as part of the Global XML Web Services Architecture (GXA) framework • It was authored by Microsoft, IBM, Verisign, and RSA Security and was released in December 2002 • WS-Trust defines concepts such as a security token service and a trust engine which are used by Web Services to authenticate other Web Services

17. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

18. WS-SecureConversation provides session-level authentication that defines conversations-specific keys • The WS-SecureConversation specification was created as part of the Global XML Web Services Architecture (GXA) framework • It was authored by Microsoft, IBM, Verisign, and RSA Security and was released in December 2002 • The specification authors conducted a WS-Trust/WS-SecureConversation interoperability workshop in November 2003 • The main entity in WS-SecureConversation is a security context token • A token that is used by both parties in a multi-message exchange as part of an established security context—also referred to as a "shared secret“ • The lifetime of a security context token extends throughout the communications session, after which it ceases to exist—hence the tighter security advantage over the message authentication model of OASIS Web Services Security

19. Web Services and Security • OASIS Web Services Security • OASIS SAML (Security Assertion Markup Language) • The Liberty Alliance • WS-Federation (Web Services Federation Language) • WS-Trust (Web Services Trust Language) • WS-SecureConversation (Web Services Secure Conversation Language) • OASIS XACML (Extensible Access Control Markup Language)

20. The OASIS XACML specification defines a standard mechanism for expressing access control policies • XACML Version 1.0 is an OASIS Standard as of February 2003 • Version 2.0 in process • XACML is based on three main concepts: • Subject: An entity (human or system) that requests access to a resource (interaction with SAML) • Resource: A data, service, or system component to which access is requested • Action: An operation on a resource (such as “read”) • A subject requests access to a resource to perform some action on that resource • The XACML Profile for Web Services (Working Draft, 29 September 2003) defines mechanisms for enforcing access control to a Web Service endpoint, as well as expressing policies in areas such as reliable messaging, privacy, trust, authentication, and cryptographic security

21. OASIS XACML’s common language for expressing security policies allows an enterprise to efficiently manage enforcement of its enterprise-wide security policies • The following rule enforces that “only members of XYZ Book Club can place orders”: <Rule Effect="Permit"> <Description> Only members of XYZ Book Club can place orders. </Description> <Condition FunctionId="and"> <Apply FunctionId="equal"> <AttributeValue>member</AttributeValue> <SubjectAttributeDesignator AttributeId="membership-status"/> </Apply> <Apply FunctionId="equal"> <AttributeValue>order</AttributeValue> <ActionAttributeDesignator AttributeId="action-id"/> </Apply> </Condition> </Rule> • This rule could be used to enforce access to Web Services as well

22. Administrative Policies in XACML Erik Rissanen mirty@sics.se Swedish Institute of Computer Science

23. Delegation • Delegation is a mechanism for administration • With delegation we mean the granting of rights for the purpose of administering access control. • We do not mean proxy delegation between tiers in an application stack.

24. The need of administrative rights • XACML has no way to specify who may change policy • Application writers need to reinvent the wheel • Models for administrative rights are needed in large systems • Many administrators are needed • Centralized administration can be a bottle neck • Centralized administration can be a security risk • Missunderstandings or too much power

25. Our approach • We have made a simple implementation of administrative rights in XACML. • We did not modify the core of XACML • Easier implementation and less intrusive • But, some things are not as elegant as they could be. • We participate in the ”real” work in the XACML TC • Note that the examples here are simplified! • Important technical details are left out

26. Administrative rights in XACML • Two sources of policies • Trusted root policies • Policies with an ”external” issuer • Two kinds of policies • Access rights • Administrative rights

27. Regular XACML Right <Policy> <Target> <Subject>Alice<Subject> <Resource>Printing</Resource> <Action>Access</Action> </Target> <Rule Effect=”Permit”> <Target><AnyTarget/></Target> </Rule> </Policy>

28. Request and response <Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action> </Request> <Response> <Decision>Permit</Decision> </Response>

29. Delegated access right • Looks like a regular XACML access right • Except it contains a condition that matches only access requests (in contrast to administrative requests) • Is in some way associated with an issuer • A digital signature for instance • Is rewritten to contain an obligation to verify the right to issue the policy

30. Delegated access right <Policy> <Target> <Subject>Alice<Subject> <Resource>Printing</Resource> <Action>Access</Action> </Target> <Rule Effect=”Permit”> <Target><AnyTarget/></Target> <Condition FunctionId="delegationMatch"> <AttributeValue DataType="delegationConstraint"/> <EnvironmentAttributeDesignator AttributeId="delegationChain"/> </Condition> </Rule> <Obligation ObligationId="authorize-issuer” FulfillOn="Permit"> <AttributeAssignment AttributeId="subject-id” >bob</AttributeAssignment> </Obligation> </Policy> Empty delegation constraint indicates access permission Bob is the issuer

31. Request and response <Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action> <Environment> <Attribute AttributeId="delegationChain"> <AttributeValue/> </Attribute> </Environment> </Request> <Response> <Decision>Permit</Decision> <Obligation ObligationId="authorize-issuer"> <AttributeAssignment AttributeId="subject-id“ >Bob</AttributeAssignment> </Obligation> </Response> Empty delegation chain indicates access request ”The decision is not valid unless the authority of Bob is verified.”

32. Simple Administrative Right • The right to create access rights • Two parts • Access permission • The scope of the access rights that are allowed in the end • Administrative subject • This is the person/people who may create policies • In the form of a condition that will match an administrative access request

33. Example Administrative Right Non-empty delegation constraint indicates administrative right. (For Bob.) <Policy> <Target> <Subject>Employee<Subject> <Resource>Printing</Resource> <Action>Access</Action> </Target> <Rule Effect=”Permit”> <Target><AnyTarget/></Target> <Condition FunctionId="delegationMatch"> <AttributeValue DataType="delegationConstraint"> <Step>Bob</Step> </AttributeValue> <EnvironmentAttributeDesignator AttributeId="delegationChain"/> </Condition> </Rule> </Policy>

34. Administrative Request <Request> <Subject>Alice</Subject> <Resource>Printing</Resource> <Action>Access</Action> <Environment> <Attribute AttributeId="delegationChain"> <AttributeValue> <Step>Bob<Step> <AttributeValue> </Attribute> </Environment> </Request> <Response> <Decision>Permit</Decision> </Response> Non-empty delegation chain indicates an administrative request. ”Verify the authority of Bob to grant this access.”

35. General Administrative Right • The right to create policies • Two parts • Access permission • The scope of the access permissions that are allowed in the end • Delegation constraint • Specifies all permitted chains of delegation in the form of a pattern that is compared with the chain of delegation in an administrative request • Depending on the condition, it may allow the creation of other administrative rights

36. General Administrative Rights Root: S1 S2 S3 S4 AP1 Issuer1: S5 S6 S7 AP2 Issuer2: S8 S9 AP3 Issuer3: S10 AP4 Issuer4: AP5 Access request: AR

37. Policy processing • The PDP owner can insert any policy into the PDP • These root policies specify which other policies may be created and by whom • External policies are rewritten to contain the verify issuer obligation • The rewritten policies are collected into the PDP • We use a single policy set in our application. • The PDP owner needs to define the policy combining algorithm • We use permit-overrides.

38. Request processing • Starts with an almost regular XACML access request: • Except an extra environment condition with an empty delegation chain • Is evaluated against the policies • Special combining algorithm collects all the obligations of delegated access permissions • The context handler has to repeat the request for each obligation until a permit is received • The issuer is added to the environment delegation chain. This indicates an administrative request. • For repeated requests the chain grows longer with each new issuer.

39. Optimization of evaluation • The current approach requires repeated access requests to verify administrative authority • If rights would be directly comparable, the verification could be done ahead of the access. • No need for repeated requests. • But also not possible to combine rights from multiple sources into a single policy. • Also would probably limit the form of policies significantly.

40. Combining algorithms • Any combining algorithm can be used within a delegated policy • When policies from multiple sources are collected, the ”PDP owner” must specify which policy combining algorithm to use

41. Policy Sets • Delegated policies could be Policy sets • Rewritten in the same way • However, Policies are enough for us • I haven’t thought about policy references yet

42. Deny • We do not use deny effects in our application • Deny should work • However, • Some policy combining algorithms may not make sense in a delegated setting. • For instance: The order of policies that are externally issued and collected into a policy set may be unpredictable.

43. Access control data in our application • Policy assertions • Attribute assertions • Attribute definition assertions • Revocations

44. Distribution of data • Data is distributed in a P2P-network, DKS • A PDP subscribes to all access control data it needs. • The PDP starts from a resource id • Fetches the resource attributes • Fetches the policies on those attributes • Fetches the issuer attributes • End user attributes are fetched from the network or uploaded by the user

45. Architecture

46. Main open issues • Difficult for people to understand dependencies? • Descriptive text in policies? • Limit policies to a comparable form? • Perhaps application semantics are enough? • Replacement of administrators • When an administrative right is removed from an administrator, other policies fall as well. This may not be desirable. • Issue instants of policies are perhaps not trusted. • History of issuer attributes would be needed. • Implementation with obligations is not elegant • Work in progress at the XACML TC • I haven’t thought about all features of XACML yet.

47. The End • More information: • http://www.sics.se/isl/pbr/xacml.html