Upload
julie-richardson
View
220
Download
4
Tags:
Embed Size (px)
Citation preview
Federating Technologies:SAML, Shibboleth,
and the Field
Scott Cantor
The Ohio State University
Internet2/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
Loose Coupling
Technical Normalization
Glosses Internal/External Distinctions
Linkage over Storage
Identity Transformation
Focused on Interchange (XML)
OASIShttp://www.oasis-open.org/
Organization for the Advancement of Structured Information Standards
Founded in 1993 as a consortium of SGML vendors
Home for self-organizing committees chartered to develop particular technologies
Achieved greater visibility with buzzword-compliance of XML and web services
SAMLhttp://ww.oasis-open.org/committees/security
Security Assertion Markup Language
OASIS standard for exchanging security and identity-related information within and between security domains
In its second generation, and has stablized
Mature standard for web-based federation
Increasingly a basis of new work
SAML Use Case Exampleshttp://www.oasis-open.org/committees/download.php/507
Third-party (verified) authentication of clients to resources within or between security domains
Single sign-on of web browser to multiple sites within or between security domains
Attribute exchange Delegating authorization decisions Attachable signed "tokens" for application
messages
SAML Background / Timeline
Initial standardization effort began in OASIS in 2001 to unify specifications submitted by Netegrity and Securant. SAML 1.0 completed and approved Nov 2002.
Liberty Alliance ID-FF 1.1 forks off SAML 1.0
SAML 1.1 completed and approved Sept 2003.
Liberty Alliance ID-FF 1.2 forks off SAML 1.1
Liberty Alliance submits ID-FF to SSTC
SAML 2.0 completed and approved March 2005
Road to Convergence
ID-FF 1.1
SAML 1.0 SAML 1.1
Shibboleth 1.x
ID-FF 1.2
SAML 2.0
2002 2003 2004
SAML 1.0 (2002)Scope of Interoperability
Source-site initiated web authentication POST Profile
Artifact / Callback Profile
Attribute exchange protocol via SOAP
Authz query/decision protocol via SOAP
Free-standing assertion format *(*) relatively untested
SAML POST Profile
Source Site
ITS
(1)
(2)
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
Destination Site
ACS
(3)
(4)
SAML Artifact Profile
Source Site
ITS
(1)
(2)
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
Destination Site
ACS
(3)
(5)
(4)
Liberty ID-FF 1.0/1.1 (2002-2003)Scope of Interoperability
IdP/SP initiated web authentication
Account linking with IdP-managed pair-wise identifiers
Authentication context
Single logout protocol
Identifier refresh / revocation
Limited configuration metadata format
SAML 1.1 (2003)
Addressed XML signature interoperability (necessary for POST profile and effective use with web services)
Specification cleanup
Managed badly, resulting in backward-incompatibility
Shibboleth 1.x (2002-2004)Scope of Interoperability SAML 1.1 with a few additions
IdP/SP initiated web authentication
Anonymity and attribute-based access control
Account linking with SAML attributes
Limited configuration metadata format
Liberty ID-FF 1.2 (2004)Scope of Interoperability Evolution of ID-FF 1.1, rebased on SAML 1.1:
"One-time" user identifiers, similar to Shibboleth’s
Richer metadata exchange
Limited use of XML Encryption
First significant exploration of SAML as a web service security mechanism in ID-WSF 1.0
SAML 2.0 (2005) Vulcan mind-meld of SAML 1.1, Shibboleth
and Liberty ID-FF 1.2 approaches and profiles Challenges:
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 Conformance Assertions
SAML as security token or wrapper, common extensible base Protocols
Synchronous message exchange involving SAML assertions or in support of SAML use cases
Bindings Concrete SAML message exchange over a transport protocol
Profiles Basic unit of interoperability applying a protocol or assertion
capability Metadata Authentication Context
SAML Assertions An XML fragment binding “statements” about a
“subject”, issued by an “authority” to one or more relying parties: Issuer Subject
Identifier Confirmation
Statements Authentication, Attribute, Authorization Decision, etc.
Conditions Validity period, audiences, obligations
Advice
SAML 2.0 Example<Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0“
ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2003-04-17T00:46:02Z">
<Issuer>https://www.opensaml.org/IDP"</Issuer>
<ds:Signature xmlns:ds="...">...</ds:Signature>
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">[email protected]</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2003-04-17T00:51:02Z"/>
</SubjectConfirmation>
</Subject>
<Conditions NotBefore="2003-04-17T00:46:02Z" NotOnOrAfter="2003-04-17T01:46:02Z">
<AudienceRestriction>
<Audience>http://www.opensaml.org/SP</Audience>
</AudienceRestriction>
</Conditions>
<AuthnStatement AuthnInstant="2003-04-17T00:46:00Z">
<AuthnContext>
<AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</AuthnContextClassRef>
</AuthnContext>
</AuthnStatement>
</Assertion>
SAML Protocols Rudimentary schema types for request/response
protocol Designed to be transport (and SOAP)-independent Supports signed messages, correlation, replay
detection Derived into specific protocols
AuthnRequest/Response LogoutRequest/Response NameIDManageRequest/Response NameIDMappingRequest/Response Attribute-Authn-AuthzDecisionQuery/Response …
SAML Bindings Given a protocol message, defines:
encoding for transport security characteristics
Synchronous SOAP URI resolution of assertions
Asynchronous HTTP U-A bindings (Redirect, POST, Artifact) PAOS (Reverse SOAP)
SAML Profiles Browser and Enhanced Client Single Sign-
On
Single Logout
NameID Management
NameID Mapping
Query Profiles
Artifact Binding Resolution
Attribute Profiles
SAML 2.0 SSO Profile (e.g.)
Identity Provider
SSOS
(3)
(4)
1. HTTP Request (non-normative) to SP
2. <samlp:AuthnRequest> encoded in URL Redirect
3. <samlp:AuthnRequest> 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
Service Provider
ACS
(5)(6)
(1)
(2)
SAML 2.0 Logout Profile (e.g.)
Identity Provider
SLOS
(3)
(4)
1. HTTP Request (non-normative) to SP
2. <samlp:LogoutRequest> encoded in URL Redirect
3. <samlp:LogoutRequest> passed to IdP SLO Service via HTTP GET
4. <samlp:LogoutResponse> encoded in URL Redirect
5. <samlp:LogoutResponse> passed to SP SLO Service via HTTP GET
6. HTTP Response
Service Provider
SLOS
(5)(6)
(1)
(2)
Emerging SAML Use Cases
Attribute exchange layered on X.509 authentication (e.g. GridShib)
SASL/GSS-API mechanism
SIP
Delegation / multi-tier scenarios
Status of Committee
OASIS doesn’t have a defined process for maintaining its specifications
Errata (non-normative?)
Additional profiles and extensions Metadata for SAML 1.x, unsupported use cases
Third-party generation of SAML requests
X.509 authentication with attribute sharing
Industry Support
Dozen or more commercial and open source SAML 1.x (and usually ID-FF 1.x) Web SSO products (software and hardware)
Microsoft ADFS uses SAML 1.1 assertions as security tokens
A few major COTS applications include SAML support, notably some ERP vendor portals
Most SAML/Liberty vendors have announced or shipped SAML 2.0 products
Latest WS-Security specs support SAML 2.0, as will Liberty ID-WSF 2.0
Shibboleth (Re)Defined Shibboleth Project
An umbrella of activities around federated authentication and access management managed by Internet2 and its international partners, still ad hoc but moving toward some formalism
Shibboleth SpecificationsThe wire protocols and conformance requirements that define
"Shibboleth Compatible", currently derived in large part from SAML 1.1
Shibboleth SystemInternet2-developed open source implementation of the
specifications plus value-added componentsNot the only extant or planned implementation (at least 2-3 other
implementations known, lots of smaller projects based on the code base)
Shibboleth (Re)(Re)DefinedShibboleth Project
An umbrella of activities around federated authentication and access management managed by Internet2 and its international partners
Shibboleth SpecificationsDeprecated?
Shibboleth SystemInternet2-developed open source implementation of the Shibboleth and SAML 2.0 specifications plus value-added components
Implementation of additional/complementary industry standards?
ShibbolethTimeline Project formation - Feb 2000
OpenSAML prerelease – July 2002
Shib v1.0 April 2003
Shib v1.2 April 2004
Shib v1.3 August 2005 (fully SAML 1.x compatible)…
OpenSAML 2.0 – Spring 2006
Shib 2.0 – Summer 2006
ShibbolethKey Concepts Federated Administration
Attribute-Based Single Sign-On
Management of Privacy through IdP
Standards Based
Framework for a Variety of Policy and Management Models
Extensible Authentication and Attribute Sharing
ShibbolethComponent Architecture
OpenSAML
Shibboleth Core Metadata Trust Credentials
SPCore
IdPCore
AttributeResolver
ARPEngine
NameIDResolver
SSO ServiceAttributeAuthority
AttributeFiltering
AccessControl
SessionCache
mod_shib, isapi_shib, etc.
Protocol HandlersProtocol Handlers
ApplicationsUser
Authentication
Shibboleth IdPApplication Model
Translates arbitrary act of authentication into SAML assertion containing claims about user
Claims (SAML attributes) can be pushed or pulled
User identity is masked in default configuration Claims to be released established by user or
administrative policy (usually the latter to date) Agnostic to authentication processes, attribute
sources (LDAP, JNDI, JDBC, custom)
Shibboleth SPApplication Model SP integrated with web platform (Apache, IIS,
Sun/iPlanet) 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 loosely-coupled 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.)
ShibbolethRecent / Future Developments US Govt E-Authentication
Extension for Microsoft ADFS interoperability
Development of SAML 2.0 support underway
Early version of ARP GUI from Australia
Preliminary discussions over extending web SSO to back-end services
Liberty Alliance Project Open membership consortium, mostly
technology vendors and large corporate customers (consumer, telecom, financial)
Members generate business requirements (MRD) and produce technical specifications or profiles of standards to address requirements
Generally a pragmatic technical approach Also explores policy issues
ID-WSF Identity Web Services Framework
Uses the “web service stack” to define services useful to the Liberty sponsors’ business models
Examples include profile, contact book, social networking, calendaring, payment services, presence, geolocation, etc.
Relies on SAML and other open specs when possible
ID-WSF Security Requirements WS clients may invoke services on their own
behalf or on behalf of other identities, such as user principals.
Authz must be potentially enforceable both by a web service and by a trusted third party.
Authz may be based on the identity of the sender, the invoker, and the presence of the resource’s owner.
Basic Security Design Use TLS or signed XML when practical to
authenticate endpoints (peer entity authn)
Use WS-Security to carry security tokens, with SAML assertions the primary example
Bundles service discovery with security token issuance and TTP policy enforcement
Profiles SAML tokens for enhanced security semantics
Why is WSF significant?
Only adequately and publically-specified profiles for securing web services
Significantly extensible and adaptable without being hopelessly general
Driving mechanisms to enable more generic use of SAML
Related OASIS Standards
XACML (eXtensible Access Control ML) http://sunxacml.sourceforge.net/
SPML (Service Provisioning ML)
WS-Security SOAP Message Security
SAML Token Profile
WS-*
Large set of functionality that reinvents or tunnels existing protocols and standards on top of SOAP (e.g. TCP, TLS, Kerberos, XA)
Mostly proprietary specifications written by IBM or Microsoft
Slowly being fed to OASIS and W3C as they bring products to market
Designed to be “composable”, but the layering isn’t particularly clean or proven in real use cases
Very Incomplete List
Submitted WS-Security WS-Addressing (W3C) WS-SX
WS-Trust WS-SecureConversation WS-SecurityPolicy
WS-TX WS-Coordination WS-AtomicTransaction
WS-ReliableMessaging
Unsubmitted WS-Policy WS-PolicyAttachment WS-PolicyAssertions WS-MetadataExchange WS-Federation
An interoperable profile for using them in a real-world use case
Infocard
Microsoft developing a proprietary profile of WS-Trust + WS-SecurityPolicy + WS-MetadataExchange
OS-integrated client to manage delivery of credentials (e.g. SAML assertions) to relying parties that support WS-Trust
Integrated with Internet Explorer Client manages multiple keys to avoid
correlation by SPs