January 19, 2005

1. xmlCoP Interoperable Trust Networks January 19, 2005 Andrew Nash Chief Technology Officer, Reactivity

2. Web Service Aggregator ExampleBrowser Redirection • Yahoo shopping portal searches for products and lowest prices across all storefronts • Search results displayed at Yahoo • Users redirected to backend web sites belonging to vendors • Interactions with vendors use browser redirects • Single Sign On achieved using SAML assertions HTTPRedirection

3. Web Service Aggregator Example • Yahoo shopping portal searches for products and lowest prices across all storefronts • Results aggregated at Yahoo instead of redirecting users to backend web sites • Common shopping, payment, shipping and query interfaces provided through Yahoo portal • Interactions with vendors use Web Service transactions • Complimentary to classic Liberty Federation using browser redirection – avoids changing look and feel WebServices HTML

4. Applications Users User and Transactional Security WebServers Business transaction model based on XML and Web Services Applications exchange transactions – users are not directly involved Sender may not originate transactions; does not know the final destination Security requirements are based on the content of transaction – not the identity of the applications Transactional Security User Security

5. Overlapping Web Security Standards User Federation Web Services WS-SecureConversation Liberty ID FF WS-Federation WS-Federation WS-Trust SAML WSS HTTP SOAP

6. Security Assertions Markup Language • Framework for exchanging security assertions • Profiles will map assertion use to messaging frameworks • Use Cases • Single Sign-On • Web user authenticates at a Web site. Web user then accesses another Web site without re-authenticating • Authorization Service • User attempts to access a resource or service. The access controller for that resource (policy enforcement point) checks the user's rights with a policy decision point • Attribute Service • User moves from one web site to another – customer loyalty information or context is passed to simplify the users experience as part of a federated information services

7. Policy Policy Policy CredentialsCollector PolicyDecisionPoint AuthenticationAuthority AttributeAuthority Authorization Decision Assertion Authentication Assertion Attribute Assertion SAML Policy Enforcement Point ApplicationRequest SystemEntity SAML Domain Model

8. SAML Assertion Request Protocol

9. Where Does Liberty Fit? • Liberty Alliance is focused on SSO and user information sharing using a federated identity model • Liberty is an application domain standard • Builds on standards defined elsewhere to solve the application domain problems • Liberty will uses SAML V2 for infrastructure support • Liberty move to WSS Liberty Alliance Other Federation Enabling Standards WS Security SAML SOAP

10. PolicyDecisionPoint Policy Enforcement Point Liberty & SAML Liberty Identity Provider Liberty Service Provider AuthenticationAuthority AttributeAuthority Authentication Assertion Attribute Assertion Authorization Decision Assertion SAML SAML SOAP Foundation

11. Name:Jack Name:JFK Name:John Liberty Identity Federation “Circle of Trust” MyCompany.com (ID Provider) BusUnit1.com PartnerA.com Federated ID SecurityDomain=“BusUnit1.com" Name=“Jack" SecurityDomain=“PartnerA.com" Name=“John" Federated ID SecurityDomain=“BusUnit1.com" Name="dTvIiRcMlpCqV6xX" SecurityDomain=“PartnerA.com" Name="pfk9uzUN9JcWmk4RF"

12. 7 6 5 4 1 3 2 1. Request Access 2. Redirect w/AuthN Request 3. Authenticate 4. Redirect w/SAML AuthN reference 5. Request SAML AuthN Assertion 6. Receive SAML AuthN Assertion 7. Grant Access Liberty/SAML Web SSO Model “Circle of Trust” Service Provider Identity Provider Authentication Authority Attribute Authority

13. IBM/Microsoft Web Services Architecture WS-Secure Conversation WS-Federation WS-Authorization WS-Policy WS-Trust WS-Privacy WS-Security SOAP Foundation StandardsBody PublishedSpecs UnpublishedSpecs

14. SOAP Message Security only, does not cover other aspects of security for web services Issuance and exchange of security tokens – not establishment and validation of trust Policy definition framework, does not describe how policies are managed How security information is passed, not how security policy is distributed or enforced What’s in a Name? • WS-Security(aka WSS) • WS-Trust • WS-Policy • WS-SecurityPolicy

15. WS-Security • Describes how to secure SOAP messages • Defines how to identify the creator of the message • Carries multiple credential types including • Message Integrity • Integrity of all or part of a message • Builds on XML-Signature • Supports multiple and overlapping signatures • Message Confidentiality • Confidentiality of all or part of a message • Builds on XML-Encrypt

16. SOAP Envelope SOAP Header Security Header SOAP Body MessageBody Securing SOAP Messages • WSS information stored in SOAP security header • One or more security tokens carried in header to identify the transaction • XML Signature blocks may be carried to provide integrity and link the identity to the transaction • Key information within the security token may be used • Privacy provided using XML encryption wsse: security token key info signature

17. Security Tokens • Separate profiles define the format and usage rules of various token types • Username/password • Binary Security Tokens • Encoding type like Base-64 allows inclusion in XRML • X.509 • Kerberos • XML Tokens • SAML • XRML • Common Biometric Format • Great … but where do we get these security tokens from…?

18. WS-Trust • A Security Token Service (STS) issues tokens that can be used in WSS • Forms the basis for several other WS-* standards (coming up) • Token issuance, renewal and validation are handled by an STS • The services of an STS may be required by web services and their clients • Security tokens are a collection of claims about a resource • The claims presented in security token are examined in the light of the policy controlling the web service

19. Web Services Trust Model Policy SecurityTokenService SecurityToken Claims Policy Requestor SecurityToken Claims Policy WebService SecurityToken Claims

20. WS-Policy • Framework for defining policies parameters or assertions that affect web services • WS-PolicyAttachment describes how policies are associated with a resource • WS-PolicyAssertions defines a common set of assertions • Establishes a mechanism for exchanging requirements between a web services provider and client • Provides machine readable policy statements that describe the operational parameters for interactions between a service and a client • Supports negotiation of the parameters defined within a policy

21. WS-Policy • Policy is defined as a series of assertions • Each has a usage (required, optional, rejected etc) and preference (ranking of this assertion) • Operators (all, exactlyone, oneormore) define how to evaluate child assertions • WS-PolicyAssertions define common assertion types • (TextEncoding, Language, SpecVersion) • WS-PolicyAttachment supports • a standalone option that allows a standalone description of the web service that the policy is associated with • Or integrated with WSDL where a series of pointers reference a policy

22. WS-SecurityPolicy • Defines assertions that address security parameters • SecurityToken identifies • Types of security tokens accepted • Issuer of the token • Optional details about particular token types (e.g. what set of user names are supported) • Integrity • What parts of a message are signed • XML signature algorithms used • Parameters defining how the algorithm should be executed

23. WS-SecurityPolicy • Confidentiality • What parts of a message are encrypted • Algorithms and parameters used • Visibility • What parts of a message must be visible to intermediary web services • SecurityHeader • Constrains how the security header is processed • MessageAge • Acceptable message lifetime based on the WSS timestamp

24. WS-SecureConversation • Eliminates the overhead of carrying and validating authentication information in each message • Establishes a mutually authenticated security context • Multiple messages may be exchanged within this context • Creates an end-to-end secured channel at the application layer • Like SSL it is provides a session oriented authenticated and encrypted data pipe • SSL is restricted to point-to-point sessions between intermediate nodes

25. WS-Federation • Describes how to share identities and attributes across multiple trust domains • Layered on WS-Trust • Tokens issued by one domains STS are used to request a new security token from the STS of another domain

26. Policy SecurityTokenService SecurityToken Federation Token Exchanges Trust Domain 1 Trust Domain 2 Policy Trust Relationship SecurityTokenService SecurityToken 1 4 2 Policy Policy Requestor WebService 3 SecurityToken SecurityToken

27. WS-Federation Sequence Web ServiceSTS RequestorSTS Requestor Web Service Rqst Security Token Issue Security Token Rqst Security Token with Token Reference Issue Security Token from Service Domain Invoke Service w Security Token Validate Security Token Approve Security Token Return Service Response

28. Security and Privacy - Today • Today transactions are secured using WSS toolkits to implement the Web Service security standards • Usually support for X.509 Certificates or password credentials SWS + password / X.509 Cert HTML

29. Security and Privacy – “Tomorrow” • SAML Tokens for use in WSS security headers to support Federated Identities • User Authentication supplied by CT/FIM • Requests SAML assertions from SAML authority to build SAML tokens • Crossover from Browser/User security world to Web Services WSS withSAML WSS + SAML Token HTML Login SAML Assertions SAML Authority

30. Security and Privacy – “Tomorrow” • Web services infrastructure moves toward WS-Trust credential servers for token issuance and support of WS-Federation • WS-Trust toolkits provide messaging and protocol support for development of clients and servers WS-Trust WSS+Token WS-Trust Server Tk WS-Federation Ids Tokens WS-TrustCredential Server

31. Svc Svc Svc Svc Svc Svc Svc Svc Svc Svc Svc Svc Web Service security dilemma Security Layer UserInterface DatabaseIntegration Business Logic CIO’s and IT Directors do not believe application programmers can verifiably implement enterprise security policies Use of toolkits does not scale to even modest deployments Tools do not exist to define, verify or modify security policy Transactions must be monitored and audited Security policy management must be federated

32. Controlling a Service Oriented Application

33. Reactivity in the enterprise

34. The Reactivity Gateway Message Pipeline

35. The Reactivity Gateway Message Pipeline

36. Multi-layer mediation of transactions • Data transformation • ex. service virtualization • Security Credential Mapping • ex. SSL external to SAML internal • Transport mapping • ex. XML/MQ to SOAP/HTTPS • Cross-layer information sharing with advanced header manipulation

37. Reactivity’s Policy Aware Core Functions Benefits Delegate & Create Policy • Optional sub-polices allow secure separation between projects, business units, geographies Collaborate & Compare Policy • Visually identify policy conflicts • Multi-stage approval for efficient workflow Deploy Policy and Mark Messages • Policy version linked to message pair ensuring consistency and auditability • One-click deploy & rollback for efficiency Report & Audit • Policy aware event and message logs enable rapid issue identification and accurate audits Policy Aware Core ensures XML Web services security with speed, flexibility and visibility Control Agility

38. Reactivity’s Vision of XML Infrastructure Application Infrastructure Server/Application Based Functions XML Infrastructure XML Message based functions – A new layer required for connecting distributed XML web services and enforcing message transport policies Network Infrastructure Packet based functions