Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • This presentation is intended to facilitate discussion about Entrust’s role in securing the Web-services architecture.
  • Basic Web-services model SOAP intermediaries may exist in the message path, including in the DMZ Security functions may be performed by a SOAP intermediary
  • Basic Web-services model SOAP intermediaries may exist in the message path, including in the DMZ Security functions may be performed by a SOAP intermediary
  • Basic Web-services model SOAP intermediaries may exist in the message path, including in the DMZ Security functions may be performed by a SOAP intermediary
  • Disadvantages Sensitive information, such as private keys sitting in the DMZ Doesn’t protect applications and data and control access to services from within the perimeter A bottleneck: even messages for low-traffic internal services have to traverse go through this control point Advantages – Enforces a strong security policy for the internal network
  • Today – policy administrators have to collaborate off-line to ensure compatible policies are implemented at client and service. If an end-point deals with many other end-points, then this collaboration could become burdensome.
  • One possible solution, particularly likely for B2B applications, the policy administrator in the service domain dictates policy. The client domain simply accepts the policy dictated to it. Some aspects of policy are solely a local matter, e.g. audit policy.
  • App server vendors may provide application firewalls for their own environments. These may have policy consoles, but they won’t be consistent with the SOAP gateway interfaces.
  • What is Network Identity?   Purpose: To give the audience an idea of what network identity is. Bottom Line Message: Our ‘identity’ involves a lot of personal information about us that is very important to us. We maintain our identity and personal information in many places on the Internet. This represents both a convenience and a challenge. This page provides a definition of what is meant by user identity. You can talk about things such as: Non-network identity - look at how many cards you have in our wallet or purse – each is a separate identity Driver’s license, credit cards, ATM cards, auto insurance cards, employee identification, health insurance cards, motor club cards, membership cards, long distance cards, frequent flyer or hotel cards, etc. Think of all the information about you that exists behind each of these identities Think of all the different places where you maintain identity that is not in your wallet or purse Employment file, health records at your doctors and hospitals, web site accounts, etc
  • What is Network Identity? Purpose: To demonstrate the different types of identity and personal information that we establish on the Internet and the challenges that maintaining this information on different sites creates. Bottom Line Message: It is difficult, insecure, and an inconvenience to maintain all these identities, user names and passwords, and personal information on multiple sites on the Internet.   This slide builds It starts with the title only and then the definition from the last page fades in, with the column to the right empty You need to ‘page down’ or click to have the column fill in with examples of different potential network identities that automatically phase in and are provided in three sections You need to ‘page down’ or click again to have those examples disappear and three bullet points appear one after the other with related points These bullets can be explained stating such things as: When users set up accounts on the Internet, they often tailor each site to meet their own preferences, including different user names and passwords Sometimes these are different and sometimes they are the same from site to site Users have a hard time remembering what they entered in each individual site, especially user names and passwords Users have to maintain the same personal information at multiple sites and when that information changes, they have to change it at each individual site or risk incorrect information existing with different accounts Keeping track of all of this is very difficult
  • Web-services

    1. 1. Web-services & Federated Identity ISSA- Motor City, March 18/04 Paul Madsen, Senior Security Consultant Entrust - Advanced Security Technologies
    2. 2. Thesis <ul><li>Web Services and federated identity both enable loosely coupled integration across autonomous domains </li></ul><ul><li>Today </li></ul><ul><ul><ul><li>Security for Web services is immature in general, e.g. SSL </li></ul></ul></ul><ul><ul><ul><li>Federation is mostly for browser based user single sign on </li></ul></ul></ul><ul><ul><ul><li>Weak connection between the two </li></ul></ul></ul><ul><li>Future </li></ul><ul><ul><li>Federated Identity fundamental building block for Web Services </li></ul></ul><ul><ul><li>Web Services fundamental building block for Federated Identity </li></ul></ul>
    3. 3. Agenda <ul><li>What’s the Connection? </li></ul><ul><li>Web Services Security </li></ul><ul><li>Federated identity </li></ul><ul><li>Federated Scenario </li></ul>
    4. 4. Web Services & Identity Inseparable <ul><li>Web Service endpoints require identities , e.g. SSL certs </li></ul><ul><li>Web Services transactions are often on behalf of an individual whose identity must flow with messages, e.g. WS-Security </li></ul><ul><li>Authorization of Web Service transactions may depend on both identities, e.g. XACML </li></ul><ul><li>Web Services emerging as standardized interface for identity-based Web Services , e.g. Liberty ID-WSF </li></ul><ul><li>Web Services emerging as default standardized interface for provisioning identities, e.g. SPML </li></ul>
    5. 5. Web Services impact on Identity Management <ul><li>Organizations have to think in new ways about identity for securing Web services </li></ul>XML-DSIG SOAP SSL/TLS WAP XML SAML HTTP XML Enc WSDL WSS UDDI Gateway Web Service Provider Domain 1 Domain 2 1. 2. 3. 4. Web Service Client
    6. 6. Multiple Identities to manage XML-DSIG SOAP SSL/TLS WAP XML SAML HTTP XML Enc WSDL WSS UDDI App 1 App 2 App 3 Domain 1 Domain 2 User Identity Invoker Identity Intermediary Identity Trusted 3 rd Party Identity
    7. 7. Agenda <ul><li>What’s the Connection? </li></ul><ul><li>Web Services Security </li></ul><ul><li>Federated identity </li></ul><ul><li>Federated Scenario </li></ul>
    8. 8. Basic Web Services Model client service execution SOAP
    9. 9. Basic Web Services Model client service service development client development development execution distribution WSDL UDDI SOAP
    10. 10. Security Components client service service development client development development security execution distribution WSDL UDDI Services Proxy Gateway Proxy
    11. 11. Security Gateway <ul><li>Sits in the DMZ, protects the internal network and internal service interfaces from the external network </li></ul><ul><li>XML-Dos attacks, terminates SSL, remote end-point authentication, coarse-grained authorization, schema validation </li></ul><ul><li>Cons </li></ul><ul><ul><li>Sensitive information such as private keys sitting in the DMZ </li></ul></ul><ul><ul><li>Doesn’t protect applications from internal attacks </li></ul></ul>
    12. 12. Today client service service development client development development security execution distribution Gateway Gateway
    13. 13. Future client service service development client development development security execution distribution Gateway Gateway WS-Policy +
    14. 14. Security Proxy <ul><li>Sits in the application environment </li></ul><ul><li>Proxies security processing for application it front-ends </li></ul><ul><li>Performs fine-grained (at least role-based) authorization </li></ul><ul><li>Applies message-level privacy policy </li></ul><ul><li>Integrates with policy management infrastructure </li></ul>
    15. 15. Security Services <ul><li>Provides security services to gateways and proxies </li></ul><ul><ul><li>Token Verification </li></ul></ul><ul><ul><li>Identification </li></ul></ul><ul><ul><li>Authorization </li></ul></ul><ul><ul><li>Etc </li></ul></ul><ul><li>Accessed through standardized Web Services interfaces </li></ul><ul><li>Allows security policy to be defined, managed, and applied consistently across enterprise </li></ul>
    16. 16. How do they help <ul><li>Security components will work together to apply policy-appropriate processing at execution time </li></ul><ul><li>May also be involved at distribution time, I.e. a services ‘unprotected’ WSDL is extended by security components to include security requirements of interface </li></ul><ul><ul><li>E.g. sign the Body of the SOAP message </li></ul></ul><ul><li>Intermediary-mediated policy negotiation </li></ul><ul><ul><li>Finding an intersection of the security policies of both enterprises </li></ul></ul>
    17. 17. Flow Sec-WSDL WSDL UDDI Query Sec-WSDL WSDL SOAP Sec-SOAP + policy Sec-SOAP SOAP SOAP SOAP Client Security Registry Security Service
    18. 18. Agenda <ul><li>What’s the Connection? </li></ul><ul><li>Web Services Security </li></ul><ul><li>Federated identity </li></ul><ul><li>Federated Scenario </li></ul>
    19. 19. What is Network Identity? A Network Identity is a user ’s overall global set of attributes constituting their various accounts
    20. 20. Network Identity? <ul><li>Multiple credentials </li></ul><ul><li>Different strengths, different apps </li></ul><ul><li>Can change </li></ul>Unique Identifier <ul><li>Subjects/principals </li></ul><ul><li>Name, number, attributes </li></ul><ul><li>Unique in some scope </li></ul><ul><li>Various ‘nyms’ </li></ul>Consumer Profiles <ul><li>Roles, entitlements, policies </li></ul><ul><li>Often specific to apps or sites </li></ul>Common Profile Info Address , etc . Credentials Credentials App, Site, or Partner Profiles Employer Profiles App, Site, or Partner Profiles
    21. 21. The Problem with Network Identity? Multiple, disconnected identities scattered across isolated Internet sites <ul><li>Inconvenient and frustrating for users </li></ul><ul><li>Expensive to support </li></ul><ul><li>Continual reauthorization to disparate systems </li></ul>
    22. 22. Federated Identity Management <ul><li>What is Identity management ? </li></ul><ul><ul><li>Set of processes, and a supporting infrastructure, for the creation, maintenance, and use of digital </li></ul></ul><ul><li>What is Federated Identity management ? </li></ul><ul><ul><li>Agreements, standards, technologies that make identity and entitlements portable across autonomous domains. </li></ul></ul>
    23. 23. What does federated identity provide? <ul><li>For browser apps, improve the end user’s experience </li></ul><ul><li>Reduce the number of logins </li></ul><ul><li>Increased effectiveness with wider scope of authorized access </li></ul><ul><li>Reduce help desk calls & simplify administration -> ROI </li></ul>
    24. 24. ‘Standards’ <ul><li>SAML </li></ul><ul><ul><li>In the lead, early adoption gaining momentum </li></ul></ul><ul><ul><li>Multiple products, open source solutions in release or development </li></ul></ul><ul><ul><li>Simple, narrow focus both best and most limiting attribute </li></ul></ul><ul><li>Liberty Alliance </li></ul><ul><ul><li>Consortium of customers & vendors </li></ul></ul><ul><ul><li>Standards effort driven (in part) by enterprise customers </li></ul></ul><ul><ul><li>Products, early implementations underway in consumer-facing apps </li></ul></ul><ul><li>WS-* Framework </li></ul><ul><ul><li>Developed by IBM and Microsoft, with help from others </li></ul></ul><ul><ul><li>Well-integrated with full Web services stack, composable architecture </li></ul></ul><ul><ul><li>Ambitious framework, broad scope, necessary but harder to create </li></ul></ul>
    25. 25. Dependencies MSFT/IBM OASIS Liberty WS-Fed (7/8/03) WS-Security 4/5/02) Phase 1 ID-FF 1.1 (1/15/03) Phase 1 ID-FF 1.0 (7/15/02) SAML 1.0 (11/5/02) SAML 1.1 (9/2/03) Phase 1 ID-FF 1.2 (11/12/03) Phase 2 ID-WSF 1.0 (11/12/03) WS-Trust (12/18/02) Phase 3 (08/04) WSS (2/04) 2003 2004 SAML 2.0 (6/04)
    26. 26. SAML <ul><li>Security Assertions Markup Language </li></ul><ul><li>Provides authentication, authorization, and attribute assertions between loosely coupled domains </li></ul><ul><li>Set of XML and SOAP-based services, protocols, and formats for exchanging authentication and authorization information </li></ul><ul><li>Emerging as interoperability syntax between different security technologies and/or realms </li></ul><ul><li>SAML 1.1 is latest OASIS Standard </li></ul><ul><ul><li>Work underway on SAML 2.0 </li></ul></ul>
    27. 27. SAML <ul><li>WS-Security profiles SAML for securing SOAP messages </li></ul><ul><li>Liberty uses SAML for Single Sign-On (SSO) in ID-FF </li></ul><ul><li>Liberty uses SAML to convey Identity to Web services in ID-WSF </li></ul><ul><li>Shibboleth uses SAML for SSO and Attributes Exchange </li></ul>SAML is a building block
    28. 28. Liberty Alliance <ul><li>Liberty is global member community defining specs for federated identity management </li></ul><ul><li>Liberty Alliance has built on SAML 1.1 to develop additional specifications </li></ul><ul><ul><li>Opt-in account linking </li></ul></ul><ul><ul><li>Session management </li></ul></ul><ul><ul><li>Authentication Context </li></ul></ul><ul><ul><li>Permission based attribute sharing </li></ul></ul>
    29. 29. Liberty Components <ul><li>ID- Federation Framework </li></ul><ul><ul><li>Enables identity federation and SSO through SAML—based messaging </li></ul></ul><ul><li>ID-Web Services Framework </li></ul><ul><ul><li>Set of foundation services and mechanisms to support identity-based services </li></ul></ul><ul><ul><ul><li>Discovery Service </li></ul></ul></ul><ul><ul><ul><li>Interaction Service </li></ul></ul></ul><ul><li>ID- Service Interface Specifications </li></ul><ul><ul><li>Definitions for identity services </li></ul></ul><ul><ul><ul><li>Personal Profile </li></ul></ul></ul><ul><ul><ul><li>Employee Profile </li></ul></ul></ul><ul><ul><ul><li>Contact Book </li></ul></ul></ul><ul><ul><ul><li>etc </li></ul></ul></ul>
    30. 30. SAML & Liberty overlap
    31. 31. SAML/Liberty convergence <ul><li>Liberty has submitted ID-FF 1.2 into the OASIS SSTC as input to SAML 2.0 </li></ul><ul><li>Further work will occur within SAML 2.0 stream </li></ul><ul><li>Liberty will continue to evolve ID-WSF and ID-SIS specs independent of SAML 2.0 efforts </li></ul>
    32. 32. WS-Federation <ul><li>Proposal from IBM/Microsoft as part of broader WS-* (includes WS-Security, WS-Policy, WS-Trust, WS-SecureConversation) </li></ul><ul><li>Released to the public mid 2003 </li></ul><ul><li>Not yet submitted to a standards body </li></ul><ul><li>Significant overlap with Liberty ID-FF/SAML </li></ul>
    33. 33. Liberty/WS-Fed convergence <ul><li>Convergence discussions ongoing between Liberty management board and IBM/MSFT </li></ul><ul><li>General agreement that the barriers are not technological, rather political </li></ul><ul><li>If convergence happens, it implies a single standard for federated identity (given the Liberty/SAML convergence) </li></ul><ul><li>If convergence doesn’t happen, it won’t be the first time that the industry has not been able to agree </li></ul>
    34. 34. Agenda <ul><li>What’s the Connection? </li></ul><ul><li>Web Services Security </li></ul><ul><li>Federated identity </li></ul><ul><li>Federated Scenario </li></ul>
    35. 35. Federated Supply Chain Scenario <ul><li>Geoff is an employee of Acme Widgets, a leading manufacturer of widgets for the thingymajig industry. </li></ul><ul><li>Geoff's role within Acme is a Junior Purchasing Agent </li></ul><ul><ul><li>Authorized to place parts orders with Acme's suppliers up to a value of $1,000 at a time </li></ul></ul><ul><li>Geoff occasionally deals with Acme's supplier Bolts-R-Us </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>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 </li></ul></ul>
    36. 36. Liberty enabled Scenario <ul><li>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 </li></ul><ul><li>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. </li></ul>
    37. 37. Geoff’s Experience <ul><li>Geoff goes to Acme's intranet portal first thing </li></ul><ul><li>Geoff logs in using an X.509 certificate issued to him by Acme </li></ul><ul><li>Geoff sees a customized Acme interface, including a link 'Order at Bolts-R-Us' </li></ul><ul><li>As he knows Acme is running low on #45 bolts, Geoff clicks on 'Order at Bolts-R-Us' link </li></ul><ul><li>Geoff sees Bolts-R-Us's ordering interface </li></ul><ul><li>Geoff orders 20,000 #45 bolts at a unit cost of $0.10. </li></ul><ul><li>Geoff see's an alert that his order has failed because the amount exceeds his purchaing amount authorization </li></ul><ul><li>Geoff changes the order to 10,000 #45 bolts. </li></ul><ul><li>Geoff sees an acknowledgement that the order has gone through. </li></ul>
    38. 38. Message Flow <ul><li>Geoff authenticates to Acme-IDP. </li></ul><ul><li>Geoff clicks on 'Order at Bolts-R-Us' button, browser is sent to Bolts-R-Us with artifact </li></ul><ul><li>Bolts-R-Us requests SAML assertion </li></ul><ul><li>Acme-IDP returns SAML assertion for Geoff containing anonymous one-time identifier for Geoff. </li></ul><ul><li>Bolts-R-Us queries Acme-EIP for Geoff's EmployeeType. </li></ul><ul><li>Acme-EP returns Geoff's EmployeeType. </li></ul><ul><li>Based on returned roles, Bolts-R-Us can make authorization decisions with respect to what resources Geoff can access. </li></ul>
    39. 39. Request/Response <s:Body>         <ep:Query>             <ep:ResourceID> http://eip.acme.com/sdfjs78 </ep:ResourceID>             <ep:QueryItem itemID=&quot;type&quot;>                 <ep:Select>/ ep:EP/ep:EmployeeType </ep:Select>             </ep:QueryItem>         </ep:Query> </s:Body> <s:Body>         <ep:QueryResponse>             <ep:Status code=&quot;ep:OK&quot;/>             <ep:Data itemIDRef=&quot;type&quot;>                 <ep:EmployeeType>                  JuniorPurchasingAgent                 </ep:EmployeeType>             </ep:Data>         </ep:QueryResponse> </s:Body> Request Response
    40. 40. Summary <ul><li>Web Services offer standard architecture for distributed computing – likely to succeed where previous attempts have failed </li></ul><ul><li>Federated Identity makes identity portable across boundaries </li></ul><ul><li>Federated identity necessary building block for future Web Service-based business transactions </li></ul><ul><li>Web Services are key enabling technology for emerging federated identity architectures </li></ul>
    41. 41. <ul><li>Thank you </li></ul>
    42. 42. Entrust Web Services Webinar <ul><li>When : </li></ul><ul><li>Wednesday, March 24 </li></ul><ul><li>11:00am </li></ul>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 Contact Duncan Hoge [email_address] 740-965-9493 Louise Popyk [email_address] 313-359-4393 http://www.entrust.com/events