Web-services & Federated Identity

1. Web-services & Federated Identity ISSA- Motor City, March 18/04 Paul Madsen, Senior Security Consultant Entrust - Advanced Security Technologies

2. Thesis • Web Services and federated identity both enable loosely coupled integration across autonomous domains • Today • Security for Web services is immature in general, e.g. SSL • Federation is mostly for browser based user single sign on • Weak connection between the two • Future • Federated Identity fundamental building block for Web Services • Web Services fundamental building block for Federated Identity

3. Agenda • What’s the Connection? • Web Services Security • Federated identity • Federated Scenario

4. Web Services & Identity Inseparable • Web Service endpoints require identities, e.g. SSL certs • Web Services transactions are often on behalf of an individual whose identity must flow with messages, e.g. WS-Security • Authorization of Web Service transactions may depend on both identities, e.g. XACML • Web Services emerging as standardized interface for identity-based Web Services, e.g. Liberty ID-WSF • Web Services emerging as default standardized interface for provisioning identities, e.g. SPML

5. Organizations have to think in new ways about identity for securing Web services Web Services impact on Identity Management Web Service Provider Gateway Web Service Client 4. 1. 3. 2. Domain 2 Domain1 SOAP XML WSDL UDDI WAP HTTP SSL/TLS XML Enc XML-DSIG WSS SAML

6. Multiple Identities to manage Trusted 3rd Party Identity App 3 App 1 App 2 User Identity Domain 2 Domain 1 Invoker Identity Intermediary Identity SOAP XML WSDL UDDI WAP HTTP SSL/TLS XML Enc XML-DSIG WSS SAML

7. Agenda • What’s the Connection? • Web Services Security • Federated identity • Federated Scenario

8. Basic Web Services Model SOAP client service execution

9. Basic Web Services Model SOAP client service execution UDDI distribution WSDL client development service development development

10. Security Components Proxy Proxy Gateway Services client service execution UDDI distribution security WSDL client development service development development

11. Security Gateway • Sits in the DMZ, protects the internal network and internal service interfaces from the external network • XML-Dos attacks, terminates SSL, remote end-point authentication, coarse-grained authorization, schema validation • Cons • Sensitive information such as private keys sitting in the DMZ • Doesn’t protect applications from internal attacks

12. Today Gateway Gateway client service execution distribution security service development client development development

13. Future Gateway Gateway client service execution WS-Policy + distribution security service development client development development

14. Security Proxy • Sits in the application environment • Proxies security processing for application it front-ends • Performs fine-grained (at least role-based) authorization • Applies message-level privacy policy • Integrates with policy management infrastructure

15. Security Services • Provides security services to gateways and proxies • Token Verification • Identification • Authorization • Etc • Accessed through standardized Web Services interfaces • Allows security policy to be defined, managed, and applied consistently across enterprise

16. How do they help • Security components will work together to apply policy-appropriate processing at execution time • May also be involved at distribution time, I.e. a services ‘unprotected’ WSDL is extended by security components to include security requirements of interface • E.g. sign the Body of the SOAP message • Intermediary-mediated policy negotiation • Finding an intersection of the security policies of both enterprises

17. Flow Client Security Registry Security Service WSDL Sec-WSDL UDDI Query Sec-WSDL WSDL SOAP SOAP Sec-SOAP + policy SOAP Sec-SOAP SOAP

18. Agenda • What’s the Connection? • Web Services Security • Federated identity • Federated Scenario

19. What is Network Identity? A Network Identity is a user’s overall global set of attributes constituting their various accounts 19

20. CommonProfileInfo Credentials App, Site, or Partner Profiles App, Site, or Partner Profiles Credentials Address, etc. Employer Profiles Network Identity? • Subjects/principals • Name, number, attributes • Unique in some scope • Various ‘nyms’ Consumer Profiles • Multiple credentials • Different strengths, different apps • Can change Unique Identifier • Roles, entitlements, policies • Often specific to apps or sites

21. The Problem with Network Identity? Multiple, disconnected identities scattered across isolated Internet sites • Inconvenient and frustrating for users • Expensive to support • Continual reauthorization to disparate systems 21

22. Federated Identity Management • What is Identity management? • Set of processes, and a supporting infrastructure, for the creation, maintenance, and use of digital • What is Federated Identity management? • Agreements, standards, technologies that make identity and entitlements portable across autonomous domains.

23. What does federated identity provide? • For browser apps, improve the end user’s experience • Reduce the number of logins • Increased effectiveness with wider scope of authorized access • Reduce help desk calls & simplify administration -> ROI

24. ‘Standards’ • SAML • In the lead, early adoption gaining momentum • Multiple products, open source solutions in release or development • Simple, narrow focus both best and most limiting attribute • Liberty Alliance • Consortium of customers & vendors • Standards effort driven (in part) by enterprise customers • Products, early implementations underway in consumer-facing apps • WS-* Framework • Developed by IBM and Microsoft, with help from others • Well-integrated with full Web services stack, composable architecture • Ambitious framework, broad scope, necessary but harder to create

25. Dependencies Liberty OASIS MSFT/IBM Phase 3 (08/04) SAML 2.0 (6/04) WSS (2/04) 2004 Phase 2 ID-WSF 1.0 (11/12/03) Phase 1 ID-FF 1.2 (11/12/03) WS-Fed (7/8/03) SAML 1.1 (9/2/03) Phase 1 ID-FF 1.1 (1/15/03) WS-Trust (12/18/02) 2003 SAML 1.0 (11/5/02) Phase 1 ID-FF 1.0 (7/15/02) WS-Security 4/5/02)

26. SAML • Security Assertions Markup Language • Provides authentication, authorization, and attribute assertions between loosely coupled domains • Set of XML and SOAP-based services, protocols, and formats for exchanging authentication and authorization information • Emerging as interoperability syntax between different security technologies and/or realms • SAML 1.1 is latest OASIS Standard • Work underway on SAML 2.0

27. SAML SAML is a building block • WS-Security profiles SAML for securing SOAP messages • Liberty uses SAML for Single Sign-On (SSO) in ID-FF • Liberty uses SAML to convey Identity to Web services in ID-WSF • Shibboleth uses SAML for SSO and Attributes Exchange

28. Liberty Alliance • Liberty is global member community defining specs for federated identity management • Liberty Alliance has built on SAML 1.1 to develop additional specifications • Opt-in account linking • Session management • Authentication Context • Permission based attribute sharing

29. Liberty Components • ID- Federation Framework • Enables identity federation and SSO through SAML—based messaging • ID-Web Services Framework • Set of foundation services and mechanisms to support identity-based services • Discovery Service • Interaction Service • ID- Service Interface Specifications • Definitions for identity services • Personal Profile • Employee Profile • Contact Book • etc

30. SAML & Liberty overlap

31. SAML/Liberty convergence • Liberty has submitted ID-FF 1.2 into the OASIS SSTC as input to SAML 2.0 • Further work will occur within SAML 2.0 stream • Liberty will continue to evolve ID-WSF and ID-SIS specs independent of SAML 2.0 efforts

32. WS-Federation • Proposal from IBM/Microsoft as part of broader WS-* (includes WS-Security, WS-Policy, WS-Trust, WS-SecureConversation) • Released to the public mid 2003 • Not yet submitted to a standards body • Significant overlap with Liberty ID-FF/SAML

33. Liberty/WS-Fed convergence • Convergence discussions ongoing between Liberty management board and IBM/MSFT • General agreement that the barriers are not technological, rather political • If convergence happens, it implies a single standard for federated identity (given the Liberty/SAML convergence) • If convergence doesn’t happen, it won’t be the first time that the industry has not been able to agree

34. Agenda • What’s the Connection? • Web Services Security • Federated identity • Federated Scenario

35. Federated Supply Chain Scenario • Geoff is an employee of Acme Widgets, a leading manufacturer of widgets for the thingymajig industry. • Geoff's role within Acme is a Junior Purchasing Agent • Authorized to place parts orders with Acme's suppliers up to a value of $1,000 at a time • Geoff occasionally deals with Acme's supplier Bolts-R-Us • Sporadic nature of Geoff's dealings there meant he often forgot both the account name and/or the password, causing delay for Geoff and support costs for Bolts-R-Us. • Bolts-R-Us has to create new accounts for Acme's new hires, an expensive process when the information needs to be verified by Acme

36. Liberty enabled Scenario • Geoff will not be required to establish an account at Bolts-R-Us. He will be able to access the appropriate resources there based on an authentication he performed to his own company • As Bolts-R-Us will not need to maintain accounts for Acme's individual Purchasing Agents, they will be unaffected as Acme's employees come and go.

37. Geoff’s Experience • Geoff goes to Acme's intranet portal first thing • Geoff logs in using an X.509 certificate issued to him by Acme • Geoff sees a customized Acme interface, including a link 'Order at Bolts-R-Us' • As he knows Acme is running low on #45 bolts, Geoff clicks on 'Order at Bolts-R-Us' link • Geoff sees Bolts-R-Us's ordering interface • Geoff orders 20,000 #45 bolts at a unit cost of $0.10. • Geoff see's an alert that his order has failed because the amount exceeds his purchaing amount authorization • Geoff changes the order to 10,000 #45 bolts. • Geoff sees an acknowledgement that the order has gone through.

38. Message Flow Geoff authenticates to Acme-IDP. Geoff clicks on 'Order at Bolts-R-Us' button, browser is sent to Bolts-R-Us with artifact Bolts-R-Us requests SAML assertion Acme-IDP returns SAML assertion for Geoff containing anonymous one-time identifier for Geoff. Bolts-R-Us queries Acme-EIP for Geoff's EmployeeType. Acme-EP returns Geoff's EmployeeType. Based on returned roles, Bolts-R-Us can make authorization decisions with respect to what resources Geoff can access.

39. Request/Response <s:Body>        <ep:Query>            <ep:ResourceID> http://eip.acme.com/sdfjs78 </ep:ResourceID>            <ep:QueryItem itemID="type">                <ep:Select>/ep:EP/ep:EmployeeType</ep:Select>            </ep:QueryItem>        </ep:Query> </s:Body> Request <s:Body>        <ep:QueryResponse>            <ep:Status code="ep:OK"/>            <ep:Data itemIDRef="type">                <ep:EmployeeType>JuniorPurchasingAgent                </ep:EmployeeType>            </ep:Data>        </ep:QueryResponse> </s:Body> Response

40. Summary • Web Services offer standard architecture for distributed computing – likely to succeed where previous attempts have failed • Federated Identity makes identity portable across boundaries • Federated identity necessary building block for future Web Service-based business transactions • Web Services are key enabling technology for emerging federated identity architectures

41. Thank you

42. Entrust Web Services Webinar Real World Customer Success with Identity Management Clerical Medical Europe will talk first hand about the success of their Web Services deployment and how Entrust enabled them to efficiently manage the digital identities of internal and external users alike When: Wednesday, March 24 11:00am Contact Duncan Hoge Duncan.Hoge@entrust.com 740-965-9493 Louise Popyk Louise.Popyk@entrust.com 313-359-4393 http://www.entrust.com/events