1 / 23

SAML 2.0: Federation Models, Use-Cases and Standards Roadmap

SAML 2.0: Federation Models, Use-Cases and Standards Roadmap. Prateek Mishra Principal identity Co-Chair, OASIS SSTC (SAML Committee). Agenda. SAML 2.0 Overview SAML 2.0 Feature Set Conclusions. SAML 2.0 Overview . Charter and Timelines Standards Family Tree Normative Specification Set

sabin
Télécharger la présentation

SAML 2.0: Federation Models, Use-Cases and Standards Roadmap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SAML 2.0: Federation Models, Use-Cases and Standards Roadmap Prateek MishraPrincipal identity Co-Chair, OASIS SSTC (SAML Committee)

  2. Agenda • SAML 2.0 Overview • SAML 2.0 Feature Set • Conclusions

  3. SAML 2.0 Overview • Charter and Timelines • Standards Family Tree • Normative Specification Set • Specification Actors and Topics

  4. Charter and Timelines • Charter adopted by the SSTC • [ENHANCE] Address issues and enhancement requests that have arisen from experience with real-world SAML implementations and with other security architectures that use SAML. • [REVISIT] Add support for features that were deferred from previous versions of SAML. • [UNIFY] Develop an approach for unifying various identity federation models found in real-world SAML implementations and SAML-based security architectures. • Timelines • First F2F meeting in September 2003 • Liberty ID-FF 1.2 submitted in November 2003 by Liberty Alliance • SSTC declares specification to be a committee draft (CD) in August 2004 • Anticipate OASIS standardization during Q4/2004

  5. Standards History LA: Liberty Alliance ID-FF: Identity Federation Framework SAML: Security Assertion Markup LanguageXACML: Extensible Access Control Markup Language Formally submitted to the SSTC SAML 2.0Q4/2004? ID-FF 1.2October 2003 LA 1.1January 2003 XACML 2.0Q4/2004? Shibboleth1H03 SAML 1.1May 2003 WSS SAML Token Profile Q4/04 WSS SOAP Security Q4/03 SAML 1.0May 2002 XACML1.0February 2003

  6. Normative Specification Set • Conformance Requirements for the OASIS SAML V2.0 • Entry point for entire specification set • Assertions and Protocols for the OASIS SAML V2.0 • SAML assertions schema [SAMLAssn-xsd] • SAML protocols schema [SAMLProt-xsd] • Bindings for the OASIS SAML V2.0 • Profiles for the OASIS SAML V2.0 • Metadata for the OASIS SAML V2.0 • SAML metadata schema [SAMLMeta-xsd] • Authentication Context for the OASIS SAML V2.0 • Various authentication context schema files • Security and Privacy Considerations for the OASIS SAML V2.0 • Glossary for the OASIS SAML V2.0

  7. Specification Actors and Topics UserClients UserClients IdentityProvider Session AuthorityAttributeProvider Service ProviderSessionParticipant Attribute Consumer Metadata IdentityFederation AttributeServices SSO SessionMngmt Trust Relationship AttributeProvider AttributeConsumer Specification Topics Actors Actors

  8. Agenda • SAML 2.0 Overview • SAML 2.0 Feature Set • Federation Models in SAML 2.0 • Conclusion

  9. SAML 2.0 Feature Set • SSO • Identity Federation • Sessions and Logout • Attribute Services • Metadata

  10. Single-Sign On • Browser-driven SSO • Form POST, SAML Artifact Profiles • Note: conformant implementations must implement both profiles • Assertions may contain attribute statements • SAML 2.0 introduces notion of attribute profile • All or certain parts of an assertion may be encrypted • Important when security intermediaries are involved • SSO for enhanced client • Enhanced client is a device that understands HTTP but not SOAP • Also has “built in” knowledge of identity provider • Examples • HTTP proxies such as a WAP gateway • Consumer device with HTTP client

  11. SAML 2.0 Feature Set • SSO • Identity Federation • What is (SAML 2.0) identity federation? • Well known name or attribute • Anonymous user Identified by attributes or roles • User identified by privacy-preserving identifier • Affiliations • Managing and updating identity federations • Privacy and user Consent • Sessions and Logout • Attribute Services • Metadata

  12. What is identity federation? • Agreement between an identity provider and one or more service providers concerning the data using which users will be described • By their e-mail address? • By their office number and employee Id? • By their role or membership in certain groups? • By a unique (privacy preserving) identifier known only to the IdP and SP? • Agreement creation may be accomplished in different ways • Business agreements between IdP and SP’s • In some cases may require bulk update or synchronization of parts of the user store at both ends

  13. Well known name or attribute • SAML 2.0 supports the use of: • Email Address • X.509 Subject Name • Windows Domain Qualified Name • Kerberos Principal Name • Attribute (e.g., employee number) • User entry at the IdP and SP(s) are keyed off the name or attribute • Privacy preservation is not an issue here • Names may be encrypted to protect against intermediaries • Common use-case in many SAML 1.X deployments

  14. Anonymous user with attributes or roles • User is never explicitly identified by a persistent identifier • A transient identifier is used as the “name” of the user • One or more roles or attributes describe the user • EmploymentLevel : Manager • AccessRights: Platinum • MemberOf: BellRingers • Access at Service Provider is given against roles or attributes • No need to maintain user entry at SP • Privacy Preserving as user identity at IdP remains unknown • Main use case in Shibboleth and some SAML 1.X deployments

  15. User identified by privacy-preserving identifier • User is identified by a persistent randomized string private to IdP and SP pairs • Unique handle per service provider • Privacy-preserving since no information about user is available at SP • Requires IdP and SP to synchronize portions of their user stores • Affiliations: important sub-case where a single persistent randomized string is shared between a set of Service Providers • Main use case in ID-FF 1.X specifications and deployments

  16. Name Identifier Management • Protocol for communicating information about name identifiers • When identifiers should be updated • Replace jsmith@foo.com by johns@foo.com • Rollover privacy preserving identifier at SP every 6 months • Update identifier at IdP with identifier meaningful to SP • When an identifier will no longer be acceptable for federation • IdP will not issue any more assertions for jsmith@foo.com • SP will not accept assertions for jsmith@foo.com

  17. Privacy and User Consent • Privacy • SAML 2.0 includes recommendations for privacy preservation if and when desired • Main idea is that Identity providers need not release any personal information about users to service providers • User Consent • SSO protocol includes ability to query and record user-consent • Identity providers and service providers can choose to provide services based on whether user-consent was obtained and recorded

  18. SAML 2.0 Feature Set • Overview • SSO • Identity Federation • Sessions and Logout • Attribute Services • Metadata

  19. Sessions and Logout • Identity providers as session authorities, service providers as session participants • Identity providers provide session identifier(s) to service providers • User may logout at IdP or SP to terminate session • Ability to terminate all or some sessions of a user • Solution follows ID-FF 1.2 closely (logout but no timeout) but also provides extension points for richer session models • Instructions for privacy preservation are provided • Multiple service providers should not be able to collude and determine if it is the “same” user who is participating in a shared session

  20. Attribute Services • Support for attribute names and values drawn from a variety of syntaxes • Basic Attribute Profile: string names and attribute values drawn from XML schema primitive type definitions • X.500/LDAP Attribute Profile: use of canonical X.500/LDAP attribute names and values • UUID Attribute Profile: Use of UUIDs as attribute names • XACML Attribute Profile: formats suitable for processing by XACML • Attributes statements may be transferred during SSO or by the use of the AttributeQuery protocol • Attributes may be encrypted to ensure end-to-end confidentiality

  21. Metadata • Identifies the distinct roles or actors involved in profiles • SSO Identity Provider • SSO Service Provider • Attribute Authority • Attribute Requester • Specifies data that must be agreed upon between system entities regarding identifiers, supported profiles, URLs, certificates and keys • Configuration data • Trust data • Will aid improved deployability of SAML components

  22. Agenda • Federation Preliminaries • Federation Agreements in SAML 2.0 • Conclusion

  23. Conclusion • SAML 2.0 integrates deployment experience from SAML 1.1 and Shibboleth, and new protocols from ID-FF 1.2 into a single standard • Supports flexible identity federation models corresponding to different business use-cases • Provides a complete solution for identity federation for web applications with no missing “last mile” pieces

More Related