Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

"Federated Identity Management"

1 241 vues

Publié le

  • Soyez le premier à commenter

"Federated Identity Management"

  1. 1. Federated Identity Management California Enterprise Architecture Program The State of California The Blueprint October 29, 2007 Draft
  2. 2. The Future is Here <ul><li>Offer new business services on the web </li></ul><ul><li>Move from silo application environment to an SOA environment </li></ul><ul><ul><li>Business services implemented as web services </li></ul></ul><ul><ul><li>Shared services across public and private </li></ul></ul><ul><li>Web services require a new security model </li></ul><ul><li>Federal Guide to Web Services Security (NIST 800-65) August 2007 </li></ul>http://csrc.nist.gov/publications/nistpubs/800-65/SP-800-65-Final.pdf
  3. 3. WS Security Standards Model Federal Guide to Security Web Services (NIST 800-65 August 2007)
  4. 4. Web Services Security <ul><li>Key Elements according to Federal Guide to Securing Web Services (NIST 800-65, August 2007) </li></ul><ul><li>Confidentiality of Web service messages using XML Encryption (W3C standard) </li></ul><ul><li>Integrity of Web service messages using XML Signature (W3C) and X.509 certificates (IETF) </li></ul><ul><li>Web service authentication and authorization </li></ul><ul><ul><li>SAML, XACML (OASIS standards) </li></ul></ul><ul><li>Web Services Security (OASIS standard) </li></ul><ul><ul><li>End-to-end SOAP messaging security </li></ul></ul><ul><li>Security for Universal Description, Discovery, and Integration (UDDI) (OASIS standard) </li></ul>
  5. 5. SOA Reference Architecture Security, Operations, & Governance Policy, Process, Monitoring, Reporting, Usage Tracking Users Browsers Voice Channel PC PDA Cell Phone IPhone IVR User Interface Platform Mainframe UNIX Windows .NET Java J2EE COBOL CICS System Administration Network Firewalls Routers XML Accelerators Proxy Servers TCP/IP Network Administration Web Services Atomic Composite Data Access Business Logic/Rules Federated Service Management “ Enterprise Service Bus ” “ Service Registry ” Orchestrated Web Services Service Discovery Service Transformations Service Mediation, Routing, Logging, Auditing Identity Policy Enforcement Messaging Management Authentication Single Sign-On Business Process Access Points Portals / Websites Web Applications ASP JSP HTML CSS User Interactions Voice/XML
  6. 6. SOA Identity Management Key Areas <ul><li>Conceptual Architecture </li></ul><ul><li>Levels of Authentication </li></ul><ul><li>Authentication Attributes </li></ul><ul><li>Identity Providers </li></ul><ul><li>ESB and Service Registry </li></ul><ul><li>Security Policy Service </li></ul><ul><li>Service Providers </li></ul><ul><li>Web Applications </li></ul><ul><li>Virtual Directory Service </li></ul><ul><li>Identity Resolution Service </li></ul><ul><li>Provisioning Users </li></ul><ul><li>Single Sign-On (SSO) </li></ul><ul><li>Example Scenarios </li></ul><ul><li>Governance </li></ul>Note: Scenario examples are illustrated at the end of the presentation
  7. 7. Identity Management & SOA Phone Call Center Voice Portal Web Web Portal Enterprise SOA Infrastructure Web Service Management Web Service Monitoring and Reporting Smart Clients Web Services Verify SSN Meds Eligibility Address Change Prof License Verification Vital Statistics Service Providers DHCS DMH DMV FTB LA County CalRHIO Business Partner DOT CDCR EDD OSHPD DCA State Employee Users Individual Business Partner County Employee Etc. Web Service Identity Providers State Employees Individuals Business Partners Basic Security Infrastructure Authentication Authorization Provisioning Auditing Enterprise Security Policy Service Virtual Directory Service Security Attributes
  8. 8. Assumptions <ul><li>Different models for some user classes </li></ul><ul><ul><li>“ One size does not fit all” </li></ul></ul><ul><li>Both Local and Enterprise environments </li></ul><ul><li>Multi-vendor environments </li></ul><ul><li>May need identity resolution if no “single truth” for identity information </li></ul><ul><li>May need virtual directory service if identity information are not in a single repository </li></ul><ul><li>Degree of “opt in” TBD for individuals </li></ul><ul><ul><li>Drives identity architecture for this user class </li></ul></ul><ul><ul><ul><li>CardSpace, self registration, rules for sharing identity information, SAML 2.0, etc. </li></ul></ul></ul>
  9. 9. State Employee IDM Model
  10. 10. Business Partner IDM Model
  11. 11. Individual IDM Model
  12. 12. Authentication Levels <ul><li>Level 1 Basic </li></ul><ul><ul><li>UserId and Password, Challenge-Response protocol </li></ul></ul><ul><li>Level 2 Single Factor </li></ul><ul><ul><li>Shared secrets, Identity Provider, SAML </li></ul></ul><ul><li>Level 3 Multi-factor </li></ul><ul><ul><li>Identity Provider, SAML, X.509 certificates </li></ul></ul><ul><ul><li>Software tokens (digitally signed and encrypted) </li></ul></ul><ul><ul><li>Hardware tokens (smart cards, etc.) </li></ul></ul><ul><ul><li>One time passwords </li></ul></ul><ul><li>Level 4 Hardware (physical) tokens only </li></ul><ul><ul><li>Typically BIO (fingerprint, voice recognition, etc.) </li></ul></ul><ul><li>Federal Electronic Authentication Guideline (NIST 800-63) </li></ul>http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf
  13. 13. Authentication Attributes <ul><li>Attributes that identify “me” </li></ul><ul><ul><li>Name, Address, DOB, Gender, Fingerprint, Birth Certificate, etc. </li></ul></ul><ul><ul><li>Shared secrets </li></ul></ul><ul><ul><ul><li>Mother’s maiden name, favorite dog’s name, etc. </li></ul></ul></ul><ul><li>Identifiers assigned to me </li></ul><ul><ul><li>UserId, Pwd, PIN, Drivers License, SSN, EmployeeId, Account Number, TaxpayerId, MedsId, etc. </li></ul></ul><ul><li>Identifiers assigned to my employer </li></ul><ul><ul><li>EmployerId, FEIN, etc. </li></ul></ul><ul><li>Attributes may be combined into authentication profiles </li></ul><ul><ul><li>Individual, State Employee, County Employee, Incorporated Business, Professional Business, etc. </li></ul></ul>
  14. 14. Identity Providers <ul><li>Performs authentication for a class of users based on the security policy </li></ul><ul><ul><li>Individual, State Employee, Business Partner, County Employee, etc. </li></ul></ul><ul><li>SAML 2.0 (OASIS standard ) is the preferred protocol and token </li></ul><ul><li>Only Identity Providers can access the Security Policy Service – so, minimize the number of Identity Providers </li></ul><ul><li>Responsible for creating the SAML token (“credential”) </li></ul><ul><li>Trust relationship with Service Providers </li></ul>
  15. 15. ESB & Service Registry <ul><li>Provides service transparency and flexibility </li></ul><ul><li>Only the Service Registry knows where the services are actually located </li></ul><ul><li>All client web applications point to the ESB </li></ul><ul><li>ESB provides message routing, transformation, mediation, logging, connectivity to other system components, and optionally, rules based routing </li></ul><ul><li>Only authorized users can create or modify information in the Service Registry. If UDDI v.3 compliant, users looking up a service can also be restricted </li></ul>
  16. 16. Security Policy Service <ul><li>Single (logical) repository for security policies for all shared services (highly available and scalable) </li></ul><ul><li>Often included in “SOA Governance” products, which may be bundled with the service registry </li></ul><ul><li>Could include: </li></ul><ul><ul><li>Authentication type (Individual, State Employee, etc.) </li></ul></ul><ul><ul><li>Authentication level (1, 2, 3, or 4) </li></ul></ul><ul><ul><li>Required attributes (UId, Pwd, Drivers License, etc.) </li></ul></ul><ul><ul><li>Attribute encryption </li></ul></ul><ul><li>Optional? Only administrators located in the Service Certification Environment can create/modify policies in the repository </li></ul><ul><ul><li>Act as proxies for the Service Providers </li></ul></ul>
  17. 17. Service Providers <ul><li>Implement business services as web services </li></ul><ul><ul><li>Can be shared externally, internally, or private </li></ul></ul><ul><li>Set the security policy for the service </li></ul><ul><li>Publish service information to the Service Registry, and security information to the Security Policy Service </li></ul><ul><li>May be written in any language that complies with web service standards (.NET, JAVA, CICS, etc.) </li></ul><ul><li>Can be part of an orchestration of web services, or call other web services </li></ul><ul><li>Are usually protected by a Policy Enforcement Point (proxy server, XML gateway, etc.) </li></ul>
  18. 18. Web Applications <ul><li>Responsible for the user session and interface (web pages) </li></ul><ul><li>Determine if security is required for a given interaction </li></ul><ul><li>Ask user for attribute information via a login form (based on request from an Identity Provider). For example, UserId, Pwd, Drivers License number, etc. </li></ul><ul><li>Create the SAML assertion or manage CardSpace card </li></ul>
  19. 19. Virtual Directory Service <ul><li>Needed if identity information is stored in more than one location. </li></ul><ul><li>Accommodates “data federation” </li></ul><ul><li>Can connect to different formats (LDAP, Active Directory, Tivoli, SQL database, etc.) </li></ul><ul><li>Some products can map attributes to a profile </li></ul>
  20. 20. Identity Resolution Service (optional) Note: Access to the Identity Resolution Service limited to Identity Providers in a Circle of Trust. Could further limit at the attribute level. Note: Minimal changes to existing databases and provisioning systems. Example: Individual ID Service could only access Master Person Profile, or FEIN attribute is excluded. Note: Could enhance fraud detection . Note: Could be anonymous . That is, the identity providers don’t need to know the source of the attribute information. Identity Resolution Service ” Master Person Profile” Name, Addr, City, State, Zip, DOB, Gender, DL, SSN, Passport, Fingerprint, Birth Certificate, MedsId, UserId, Pwd, PIN Individual Identity Service ” Master Person Profile” State Employee Id Service ” Master State Employee Profile” DOJ Name: Jonathan Landers Addr: 1234 Cimarron Dr. City: Sacramento DOB: 10/19/1970 Passport: 12345678 DMV Name: John Landers Addr: 1234 Massachusetts City: Sacramento DOB: 10/19/1970 Gender: M Drivers License: M123456 Fingerprint: Y DMV Name: Johnny Landers Addr: 1234 Simeron Dr. City: Sacramento DOB: 10/19/1970 Gender: M Drivers License: M123456 Fingerprint: Y DHCS Name: John E. Landers Addr: 1324 Cimarron Dr. City: Sacramento DOB: 10/19/1970 SSN: 512-00-1234 MedsId: X3984P Birth Certificate: Y State Portal Name: John Landers Addr: 1234 Cimarron Dr. City: Sacramento DOB: 10/19/1970 UserId: jlanders Pwd: xxxx
  21. 21. Provisioning Users <ul><li>Depends on the following policies: </li></ul><ul><ul><li>Will there be a “single truth” for a given user? </li></ul></ul><ul><ul><li>Will all user attributes be in one location? </li></ul></ul><ul><ul><li>Will the State Portal handle some level of authentication? </li></ul></ul><ul><ul><li>Level of user “opt-in” </li></ul></ul><ul><ul><li>Trust model </li></ul></ul>
  22. 22. Web Single Sign-On (SSO) <ul><li>Circle of Trusts </li></ul><ul><li>Small number of Identity Providers </li></ul><ul><li>Based on SAML </li></ul><ul><li>Depends on security policies </li></ul><ul><ul><li>Additional attributes might be required </li></ul></ul><ul><ul><li>Higher level authentication might be required </li></ul></ul><ul><li>“Reduced” sign-on is probably achievable </li></ul>
  23. 23. Example Scenario Individual User – State Portal
  24. 24. Example Scenario Individual User – All levels
  25. 25. Example Scenario Business Partner
  26. 26. Governance Matrix
  27. 27. Roadmap Q3 07 Q3 08 SOA & IDM vision SOA Governance Group Adopt vision Enterprise SOA Infrastructure Enterprise Identity Management Infrastructure Individual Identity Service State Employee Identity Service County Employee Identity Service Business Partner Identity Services Q4 07 Q1 08 Q2 08 Q4 08 Provide Interoperability Standards Establish Service Certification Process Recommendations for Sustaining Enterprise SOA Publish Standard SOA & IdM Language State CIO set SOA & IdM Policy Enterprise SOA & IdM Roadmap Make PKI decision
  28. 28. Questions [email_address] 916-739-7637