Federating Technologies: SAML, Shibboleth, and the Field Scott Cantor cantor. 2@osu. edu The Ohio State University Internet 2/MACE © Scott Cantor 2006. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.
Outline Introductions Federated Identity SAML Shibboleth Liberty Alliance Other Activities
Federated Identity Concepts l Loose Coupling l Technical Normalization l Glosses Internal/External Distinctions l Linkage over Storage l Identity Transformation l Focused on Interchange (XML)
OASIS http: //www. oasis-open. org/ l Organization for the Advancement of Structured Information Standards l Founded in 1993 as a consortium of SGML vendors l Home for self-organizing committees chartered to develop particular technologies l Achieved greater visibility with buzzwordcompliance of XML and web services
SAML http: //ww. oasis-open. org/committees/security l Security Assertion Markup Language l OASIS standard for exchanging security and identity-related information within and between security domains l In its second generation, and has stablized l Mature standard for web-based federation l Increasingly a basis of new work
SAML Use Case Examples http: //www. oasis-open. org/committees/download. php/507 l Third-party (verified) authentication of clients to resources within or between security domains l Single sign-on of web browser to multiple sites within or between security domains l Attribute exchange l Delegating authorization decisions l Attachable signed "tokens" for application messages
SAML Background / Timeline l Initial standardization effort began in OASIS in 2001 to unify specifications submitted by Netegrity and Securant. l SAML 1. 0 completed and approved Nov 2002. l Liberty Alliance ID-FF 1. 1 forks off SAML 1. 0 l SAML 1. 1 completed and approved Sept 2003. l Liberty Alliance ID-FF 1. 2 forks off SAML 1. 1 l Liberty Alliance submits ID-FF to SSTC l SAML 2. 0 completed and approved March 2005
Road to Convergence ID-FF 1. 1 SAML 1. 0 ID-FF 1. 2 SAML 1. 1 SAML 2. 0 Shibboleth 1. x 2002 2003 2004
SAML 1. 0 (2002) Scope of Interoperability l Source-site initiated web authentication l POST Profile l Artifact / Callback Profile l Attribute exchange protocol via SOAP l Authz query/decision protocol via SOAP l Free-standing assertion format * (*) relatively untested
SAML POST Profile Source Site Destination Site ITS ACS (2) (1) (3) (4) 1. HTTP Request (non-normative) to Intersite Transfer Service 2. Signed <samlp: Response> in HTML FORM (action=POST) 3. HTTP POST to Assertion Consumer Service 4. HTTP Response
SAML Artifact Profile (4) Source Site Destination Site ITS ACS (2) (3) (1) (5) 1. HTTP Request (non-normative) to Intersite Transfer Service 2. HTTP Redirect with SAMLart Parameter 3. HTTP GET to Assertion Consumer Service with SAMLart Parameter 4. SAML SOAP Query / Response (authenticated exchange) 5. HTTP Response
Liberty ID-FF 1. 0/1. 1 (2002 -2003) Scope of Interoperability l Id. P/SP initiated web authentication l Account linking with Id. P-managed pair-wise identifiers l Authentication context l Single logout protocol l Identifier refresh / revocation l Limited configuration metadata format
SAML 1. 1 (2003) l Addressed XML signature interoperability (necessary for POST profile and effective use with web services) l Specification cleanup l Managed badly, resulting in backwardincompatibility
Shibboleth 1. x (2002 -2004) Scope of Interoperability l SAML 1. 1 with a few additions l Id. P/SP initiated web authentication l Anonymity and attribute-based access control l Account linking with SAML attributes l Limited configuration metadata format
Liberty ID-FF 1. 2 (2004) Scope of Interoperability l Evolution of ID-FF 1. 1, rebased on SAML 1. 1: l "One-time" user identifiers, similar to Shibboleth’s l Richer metadata exchange l Limited use of XML Encryption l First significant exploration of SAML as a web service security mechanism in ID-WSF 1. 0
SAML 2. 0 (2005) l Vulcan mind-meld of SAML 1. 1, Shibboleth and Liberty ID-FF 1. 2 approaches and profiles l Challenges: l l l Incorporate ID-FF technical solutions into a generalized SAML framework Manage increase in size of specification Maintain momentum, consistency Begin to support non-browser use cases in a consistent fashion (including, but not limited to, web services) Increased politicization
Refactored SAML 2. 0 Specifications l Conformance l Assertions l l Protocols l l Synchronous message exchange involving SAML assertions or in support of SAML use cases Bindings l l SAML as security token or wrapper, common extensible base Concrete SAML message exchange over a transport protocol Profiles l Basic unit of interoperability applying a protocol or assertion capability l Metadata l Authentication Context
SAML Assertions l An XML fragment binding “statements” about a “subject”, issued by an “authority” to one or more relying parties: l l Issuer Subject l l l Statements l l Authentication, Attribute, Authorization Decision, etc. Conditions l l Identifier Confirmation Validity period, audiences, obligations Advice
SAML 2. 0 Example <Assertion xmlns="urn: oasis: names: tc: SAML: 2. 0: assertion" Version="2. 0“ ID="_a 75 adf 55 -01 d 7 -40 cc-929 f-dbd 8372 ebdfc" Issue. Instant="2003 -04 -17 T 00: 46: 02 Z"> <Issuer>https: //www. opensaml. org/IDP"</Issuer> <ds: Signature xmlns: ds=". . . ">. . . </ds: Signature> <Subject> <Name. ID Format="urn: oasis: names: tc: SAML: 1. 1: nameid-format: email. Address"> scott@example. org</Name. ID> <Subject. Confirmation Method="urn: oasis: names: tc: SAML: 2. 0: cm: bearer"> <Subject. Confirmation. Data Not. Before="2003 -04 -17 T 00: 46: 02 Z" Not. On. Or. After="2003 -04 -17 T 00: 51: 02 Z"/> </Subject. Confirmation> </Subject> <Conditions Not. Before="2003 -04 -17 T 00: 46: 02 Z" Not. On. Or. After="2003 -04 -17 T 01: 46: 02 Z"> <Audience. Restriction> <Audience>http: //www. opensaml. org/SP</Audience> </Audience. Restriction> </Conditions> <Authn. Statement Authn. Instant="2003 -04 -17 T 00: 46: 00 Z"> <Authn. Context. Class. Ref>urn: oasis: names: tc: SAML: 2. 0: ac: classes: Password</ Authn. Context. Class. Ref> </Authn. Context> </Authn. Statement> </Assertion>
SAML Protocols l l Rudimentary schema types for request/response protocol Designed to be transport (and SOAP)-independent Supports signed messages, correlation, replay detection Derived into specific protocols l l l Authn. Request/Response Logout. Request/Response Name. IDManage. Request/Response Name. IDMapping. Request/Response Attribute-Authn-Authz. Decision. Query/Response …
SAML Bindings l Given a protocol message, defines: l l l Synchronous l l l encoding for transport security characteristics SOAP URI resolution of assertions Asynchronous l l HTTP U-A bindings (Redirect, POST, Artifact) PAOS (Reverse SOAP)
SAML Profiles l Browser and Enhanced Client Single Sign-On l Single Logout l Name. ID Management l Name. ID Mapping l Query Profiles l Artifact Binding Resolution l Attribute Profiles
SAML 2. 0 SSO Profile (e. g. ) Identity Provider Service Provider SSOS ACS (4) (5) (6) (3) (1) (2) 1. HTTP Request (non-normative) to SP 2. <samlp: Authn. Request> encoded in URL Redirect 3. <samlp: Authn. Request> passed to SSO Service via HTTP GET 4. <samlp: Response> in HTML FORM (action=POST) containing signed < saml: Assertion> 5. HTTP POST to Assertion Consumer Service 6. HTTP Response
SAML 2. 0 Logout Profile (e. g. ) Identity Provider Service Provider SLOS (4) (5) (6) (3) (1) (2) 1. HTTP Request (non-normative) to SP 2. <samlp: Logout. Request> encoded in URL Redirect 3. <samlp: Logout. Request> passed to Id. P SLO Service via HTTP GET 4. <samlp: Logout. Response> encoded in URL Redirect 5. <samlp: Logout. Response> passed to SP SLO Service via HTTP GET 6. HTTP Response
Emerging SAML Use Cases l Attribute exchange layered on X. 509 authentication (e. g. Grid. Shib) l SASL/GSS-API mechanism l SIP l Delegation / multi-tier scenarios
Status of Committee l OASIS doesn’t have a defined process for maintaining its specifications l Errata (non-normative? ) l Additional profiles and extensions l Metadata for SAML 1. x, unsupported use cases l Third-party generation of SAML requests l X. 509 authentication with attribute sharing
Industry Support l Dozen or more commercial and open source SAML 1. x (and usually ID-FF 1. x) Web SSO products (software and hardware) l Microsoft ADFS uses SAML 1. 1 assertions as security tokens l A few major COTS applications include SAML support, notably some ERP vendor portals l Most SAML/Liberty vendors have announced or shipped SAML 2. 0 products l Latest WS-Security specs support SAML 2. 0, as will Liberty ID-WSF 2. 0
Shibboleth (Re)Defined l Shibboleth Project l An umbrella of activities around federated authentication and access management managed by Internet 2 and its international partners, still ad hoc but moving toward some formalism l Shibboleth Specifications l The wire protocols and conformance requirements that define "Shibboleth Compatible", currently derived in large part from SAML 1. 1 l Shibboleth System l Internet 2 -developed open source implementation of the specifications plus value-added components l Not the only extant or planned implementation (at least 2 -3 other implementations known, lots of smaller projects based on the code base)
Shibboleth (Re)Defined l Shibboleth Project l. An umbrella of activities around federated authentication and access management managed by Internet 2 and its international partners l Shibboleth Specifications l. Deprecated? l Shibboleth System l. Internet 2 -developed open source implementation of the Shibboleth and SAML 2. 0 specifications plus valueadded components l. Implementation of additional/complementary industry standards?
Shibboleth Timeline l Project formation - Feb 2000 l Open. SAML prerelease – July 2002 l Shib v 1. 0 April 2003 l Shib v 1. 2 April 2004 l Shib v 1. 3 August 2005 (fully SAML 1. x compatible) … l Open. SAML 2. 0 – Spring 2006 l Shib 2. 0 – Summer 2006
Shibboleth Key Concepts l Federated Administration l Attribute-Based Single Sign-On l Management of Privacy through Id. P l Standards Based l Framework for a Variety of Policy and Management Models l Extensible Authentication and Attribute Sharing
Shibboleth Component Architecture User Authentication SSO Service Applications Attribute Authority mod_shib, isapi_shib, etc. Protocol Handlers Id. P Core Name. ID Attribute ARP Resolver Engine Protocol Handlers SP Core Shibboleth Core Metadata Open. SAML Session Attribute Access Cache Filtering Control Trust Credentials
Shibboleth Id. P Application Model l Translates arbitrary act of authentication into SAML assertion containing claims about user l Claims (SAML attributes) can be pushed or pulled l User identity is masked in default configuration l Claims to be released established by user or administrative policy (usually the latter to date) l Agnostic to authentication processes, attribute sources (LDAP, JNDI, JDBC, custom)
Shibboleth SP Application Model l l SP integrated with web platform (Apache, IIS, Sun/i. Planet) validates SAML assertions and filters/processes the claims while providing session management (SAML token in, cookie out) Applications generally written in terms of processed claims, but may access raw tokens Interface between applications and claims is looselycoupled and HTTP-centric (server environment variables) Applications with existing security token mgmt can use a trivial “stub” application to translate incoming claims (store them in a database by session key, encrypt into cookie, map to local account or group, etc. )
Shibboleth Recent / Future Developments l US Govt E-Authentication l Extension for Microsoft ADFS interoperability l Development of SAML 2. 0 support underway l Early version of ARP GUI from Australia l Preliminary discussions over extending web SSO to back-end services
Liberty Alliance Project l Open membership consortium, mostly technology vendors and large corporate customers (consumer, telecom, financial) l Members generate business requirements (MRD) and produce technical specifications or profiles of standards to address requirements l Generally a pragmatic technical approach l Also explores policy issues
ID-WSF l Identity Web Services Framework l Uses the “web service stack” to define services useful to the Liberty sponsors’ business models l Examples include profile, contact book, social networking, calendaring, payment services, presence, geolocation, etc. l Relies on SAML and other open specs when possible
ID-WSF Security Requirements l WS clients may invoke services on their own behalf or on behalf of other identities, such as user principals. l Authz must be potentially enforceable both by a web service and by a trusted third party. l Authz may be based on the identity of the sender, the invoker, and the presence of the resource’s owner.
Basic Security Design l Use TLS or signed XML when practical to authenticate endpoints (peer entity authn) l Use WS-Security to carry security tokens, with SAML assertions the primary example l Bundles service discovery with security token issuance and TTP policy enforcement l Profiles SAML tokens for enhanced security semantics
Why is WSF significant? l Only adequately and publically-specified profiles for securing web services l Significantly extensible and adaptable without being hopelessly general l Driving mechanisms to enable more generic use of SAML
Related OASIS Standards l XACML (e. Xtensible Access Control ML) l http: //sunxacml. sourceforge. net/ l SPML (Service Provisioning ML) l WS-Security l SOAP Message Security l SAML Token Profile
WS-* l Large set of functionality that reinvents or tunnels existing protocols and standards on top of SOAP (e. g. TCP, TLS, Kerberos, XA) l Mostly proprietary specifications written by IBM or Microsoft l Slowly being fed to OASIS and W 3 C as they bring products to market l Designed to be “composable”, but the layering isn’t particularly clean or proven in real use cases
Very Incomplete List Submitted l l l WS-Security WS-Addressing (W 3 C) WS-SX l l WS-TX l l l WS-Trust WS-Secure. Conversation WS-Security. Policy WS-Coordination WS-Atomic. Transaction WS-Reliable. Messaging Unsubmitted l l l WS-Policy. Attachment WS-Policy. Assertions WS-Metadata. Exchange WS-Federation An interoperable profile for using them in a real-world use case
Infocard l Microsoft developing a proprietary profile of WS-Trust + WS-Security. Policy + WSMetadata. Exchange l OS-integrated client to manage delivery of credentials (e. g. SAML assertions) to relying parties that support WS-Trust l Integrated with Internet Explorer l Client manages multiple keys to avoid correlation by SPs
Скачать презентацию Federating Technologies SAML Shibboleth and the Field Scott
ec02802474f4c070def7757e89ca9761.ppt