saml-v1_x-tech-overview-dec05 1
Security Assertion Markup Language
SAML 1.x Technical Overview
NCSA
saml-v1_x-tech-overview-dec05 3
SAML 1.0• SAML 1.0 was adopted as an OASIS
standard in Nov 2002
• SAML has undergone one minor (V1.1) and one major (V2.0) revision since V1.0
• SAML 1.0 Interestingly, the Fed E-Authentication Initiative has adopted SAML 1.0 as its core technology
saml-v1_x-tech-overview-dec05 4
E-Authentication• The E-Authentication Initiative publishes
standards and tests implementations:http://www.cio.gov/eauthentication/
• Currently, the E-Auth Interop Lab tests vendor products for compatibility with the SAML 1.0 Browser/Artifact Profile
• Some form of SAML 2.0 compatibility testing is expected to begin soon
saml-v1_x-tech-overview-dec05 5
SAML 1.0 and 1.1 Diffs• Versions 1.0 and 1.1 of SAML are similar:
Differences between OASIS Security Assertion Markup Language (SAML) V1.1 and V1.0
• In what follows, we concentrate on SAML 1.1 since it is the definitive standard
• Currently, most other standards and implementations depend on SAML 1.1
saml-v1_x-tech-overview-dec05 7
SAML 1.1• SAML 1.1 was ratified as an OASIS
standard in Sep 2003
• SAML 1.1 is the definitive standard underlying many web browser SSO solutions in the identity management problem space
• Other important use cases besides browser SSO have emerged
saml-v1_x-tech-overview-dec05 8
SAML 1.1 Specifications• Assertions and Protocol
http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf • Bindings and Profiles
http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf • Security and Privacy Considerations
http://www.oasis-open.org/committees/download.php/3404/oasis-sstc-saml-sec-consider-1.1.pdf • Conformance Program Specification
http://www.oasis-open.org/committees/download.php/3402/oasis-sstc-saml-conform-1.1.pdf • Glossary
http://www.oasis-open.org/committees/download.php/3401/oasis-sstc-saml-glossary-1.1.pdf
saml-v1_x-tech-overview-dec05 9
SAML 1.1 Schema• SAML uses XML Schema as the
specification language
• Assertion Schemahttp://www.oasis-open.org/committees/download.php/3408/oasis-sstc-saml-schema-assertion-1.1.xsd
• Protocol Schemahttp://www.oasis-open.org/committees/download.php/3407/oasis-sstc-saml-schema-protocol-1.1.xsd
• Namespace prefixes:– xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"– xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
saml-v1_x-tech-overview-dec05 10
SAML 1.1 Use Cases• As specified, SAML 1.1 use cases are
– strictly browser-based– IdP-first
• Other use cases have been developed outside the OASIS TC, including:– WS-Security SAML Token Profile– Liberty ID-FF– Globus Toolkit Authz callout
saml-v1_x-tech-overview-dec05 12
SAML 1.1 Assertions• SAML assertions are transferred from
identity providers to service providers • Assertions contain statements that SPs
use to make access control decisions • Three types of statements are specified
by SAML:1. Authentication statements 2. Attribute statements 3. Authorization decision statements
saml-v1_x-tech-overview-dec05 13
Assertion Example• A typical SAML 1.1 assertion stub:
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" MajorVersion="1" MinorVersion="1" AssertionID="a75adf55-01d7-40cc-929f-dbd8372ebdfc" IssueInstant="2004-12-05T09:22:02Z" Issuer="https://idp.org/shibboleth"> <saml:Conditions NotBefore="2004-12-05T09:17:02Z" NotOnOrAfter="2004-12-05T09:27:02Z"/> <!-- insert statement here --></saml:Assertion>
• The value of the Issuer attribute is the unique identifier of the IdP
saml-v1_x-tech-overview-dec05 14
SAML 1.1 Statements• SAML 1.1 statement syntax:
– <AuthenticationStatement>– <AttributeStatement>– <AuthorizationDecisionStatement>
saml-v1_x-tech-overview-dec05 15
Authentication Assertions• An authentication assertion contains a subject-based
authentication statement:<saml:AuthenticationStatement AuthenticationInstant="2004-12-05T09:22:00Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="https://idp.org/shibboleth"> [email protected] </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:artifact </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject></saml:AuthenticationStatement>
• This form is used in the Browser/Artifact Profile
saml-v1_x-tech-overview-dec05 16
Authentication Assertions (cont’d)
• The following authn statement preserves privacy:<saml:AuthenticationStatement AuthenticationInstant="2004-12-05T09:22:00Z“ AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"> <saml:Subject> <saml:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier“ NameQualifier="https://idp.org/shibboleth"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameIdentifier> <saml:SubjectConfirmation> <saml:ConfirmationMethod> urn:oasis:names:tc:SAML:1.0:cm:bearer </saml:ConfirmationMethod> </saml:SubjectConfirmation> </saml:Subject></saml:AuthenticationStatement>
• This form might be used in the Browser/POST Profile
saml-v1_x-tech-overview-dec05 17
Authentication Method• SAML 1.1 specifies numerous (11) AuthenticationMethod identifiers:urn:oasis:names:tc:SAML:1.0:am:passwordurn:ietf:rfc:1510 (i.e., Kerberos)urn:oasis:names:tc:SAML:1.0:am:X509-PKIurn:oasis:names:tc:SAML:1.0:am:unspecifiedetc.
• These identifiers describe (to an SP) an authentication act that occurred in the past
• SAML2 extends this notion…
saml-v1_x-tech-overview-dec05 18
Attribute Assertions• An attribute assertion contains an attribute statement:
<saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier Format="urn:mace:shibboleth:1.0:nameIdentifier" NameQualifier="https://idp.org/shibboleth"> 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 </saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName="urn:mace:dir:attribute-def:eduPersonAffiliation" AttributeNamespace="urn:mace:shibboleth:1.0:attributeNamespace:uri"> <saml:AttributeValue> faculty </saml:AttributeValue> </saml:Attribute></saml:AttributeStatement>
• No SAML 1.1 attribute profiles exist
saml-v1_x-tech-overview-dec05 19
Authorization Decision Assertions
• An authorization decision assertion contains an authorization decision statement
• Authorization decisions are out of scope in a typical SAML deployment
• An interesting use case is the grid-based authz callout:http://users.sdsc.edu/~chandras/Papers/ccgrid-submission.pdf
saml-v1_x-tech-overview-dec05 20
Hybrid Assertions• A single assertion may include multiple
statements
• Multiple authentication statements and/or attribute statements are permitted (use cases?)
• A single assertion may include both authentication and attribute statements
saml-v1_x-tech-overview-dec05 21
SAML Subject• In a statement, the SAML Subject is important:
<saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" NameQualifier="https://idp.org/shibboleth"> [email protected] </saml:NameIdentifier> …</saml:Subject>
• In this example, the Format of the NameIdentifier is an emailAddress, a transparent, persistent identifier
• In deployments where privacy is an issue, an opaque, transient identifier is more appropriate
• Unfortunately, SAML 1.1 does not specify such an identifier
saml-v1_x-tech-overview-dec05 22
SAML Protocol• Two protocol flows: push and pull• In the pull case, the SP initiates the exchange
by first sending a query to the IdP• The query is wrapped in a <samlp:Request>
element• The IdP responds with a SAML assertion
wrapped in a <samlp:Response> element• Alternatively, the response is pushed from the
IdP to the SP by the browser user
saml-v1_x-tech-overview-dec05 23
SAML 1.1 Response• A basic SAML Response element:
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" InResponseTo="aaf23196-1773-2113-474a-fe114412ab72" IssueInstant="2004-12-05T09:22:05Z" MajorVersion="1" MinorVersion="1" ResponseID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"> <samlp:Status> <samlp:StatusCode Value="samlp:Success"/> </samlp:Status> <!-- insert SAML assertion here --></samlp:Response>
• In the pull case, the response is preceded by a request
saml-v1_x-tech-overview-dec05 24
SAML 1.1 Request• Similarly, a SAML Request element:
<samlp:Request xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" MajorVersion="1" MinorVersion="1" IssueInstant="2004-12-05T09:22:04Z" RequestID="aaf23196-1773-2113-474a-fe114412ab72"> <!-- insert SAML query here --></samlp:Request>
• There are a handful of specified SAML queries and a couple of extension points to construct your own
saml-v1_x-tech-overview-dec05 25
SAML 1.1 Queries• An SP queries for assertions with:
– <samlp:AuthenticationQuery>– <samlp:AttributeQuery>– <samlp:AuthorizationDecisionQuery>
• There is also an abstract extension point for arbitrary subject-based queries:– <samlp:SubjectQuery>
• A totally general abstract extension point:– <samlp:Query>
saml-v1_x-tech-overview-dec05 26
SAML 1.1 Queries (cont’d)
• Of all the queries, <samlp:AttributeQuery> is most used
• On the other hand, <samlp:AuthenticationQuery> is least used since authn assertions are usually pushed
• Two other query elements are specified:– <saml:AssertionIDReference>– <samlp:AssertionArtifact>
• The latter is used in the Browser/Artifact profile
saml-v1_x-tech-overview-dec05 28
SAML 1.1 Bindings• SAML 1.1 specifies just one binding (but
allows others)
• The SAML SOAP Binding specifies SOAP 1.1
• Only the SOAP body is used by SAML
• Use of SOAP over HTTP is specified (but other substrates are not precluded)
saml-v1_x-tech-overview-dec05 29
SAML 1.1 Profiles• SAML 1.1 specifies two profiles:
– Browser/POST Profile– Browser/Artifact Profile
• These browser profiles are cross-domain single sign-on (SSO) profiles
• No other profiles are specified in this version of SAML
saml-v1_x-tech-overview-dec05 30
SAML 1.1 SSO Profiles• SAML SSO profiles are browser-based
– Other uses of SAML are not specified
• SAML Browser/POST Profile– Authentication assertion by value (push)
• SAML Browser/Artifact Profile– Authentication assertion by reference (pull)
• Both SAML profiles are IdP-first– Details follow
saml-v1_x-tech-overview-dec05 31
Browser/POST Profile
• The client hand-carries an authentication assertion from the IdP to SP
• We assume the client has already authenticated and possesses a security context at the IdP
6
5
4
3
2
1
Identity Provider
Service Provider
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 32
1
Identity Provider
Service Provider
Browser/POST Step 1• The user requests
the Inter-site Transfer Service at the IdP
• The GET request includes a TARGET parameter
• Assume a security context already exists (out of scope)
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 33
Browser/POST Step 1• The browser user requests the Inter-site
Transfer Service at the IdP:https://idp.org/TransferService?TARGET=target
• The TARGET value is the location of the desired resource at the SP
• SAML does not specify how the URL to the Transfer Service is obtained
• Presumably, the user authenticates into a portal at the IdP
saml-v1_x-tech-overview-dec05 34
2
1
Identity Provider
Service Provider
Browser/POST Step 2• The IdP responds
with an HTML form• The form contains a TARGET element (from the request) and a SAMLResponse element
• The value of the SAMLResponse element is the base64 encoding of a SAML Response
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 35
Browser/POST Step 2• The Transfer Service returns an HTML FORM:
<form method="post" action="https://sp.org/ACS/POST" ...> <input type="hidden" name="TARGET" value="target" /> <input type="hidden" name="SAMLResponse" value="response" /> ...</form>
• The SAMLResponse value is the base64 encoding of a SAML Response element
• The SAML Response must be digitally signed by the IdP
saml-v1_x-tech-overview-dec05 36
3
2
1
Identity Provider
Service Provider
Browser/POST Step 3• The user POSTs
the form to the Assertion Consumer Service at the SP
• The request includes TARGET and SAMLResponse parameters from the form
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 37
Browser/POST Step 3• The client issues a POST request to the
Assertion Consumer Service at the SP• JavaScript may be used to automate the
submission of the form:window.onload = function () {document.forms[0].submit();}
• A submit button is provided in case the JavaScript fails
saml-v1_x-tech-overview-dec05 38
4
3
2
1
Identity Provider
Service Provider
Browser/POST Step 4• The Assertion
Consumer Service validates the signature on the SAML Response and creates a security context at the SP
• The SP redirects the client to the target resource
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 39
5
4
3
2
1
Identity Provider
Service Provider
Browser/POST Step 5• The client
requests the desired resource
• The resource is protected, that is, only clients with an appropriate security context are allowed
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 40
6
5
4
3
2
1
Identity Provider
Service Provider
Browser/POST Step 6• Since the client
possesses the necessary security context, access is allowed
• The requested resource is returned to the client
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
saml-v1_x-tech-overview-dec05 41
IdP-first vs. SP-first• If the client requests the resource
without a corresponding security context, access will be denied
• The SAML 1.1 browser profiles are IdP-first for simplicity
• SP-first profiles introduce some complex issues (such as IdP Discovery)
saml-v1_x-tech-overview-dec05 42
8
7
6
54
3
2
1
Identity Provider
Service Provider
Browser/Artifact Profile• In this case, the IdP
chooses to issue an artifact in lieu of an actual authentication assertion
• Again, we assume the client possesses the necessary security context at the IdP
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 43
1
Identity Provider
Service Provider
Browser/Artifact Step 1• The user requests
the Inter-site Transfer Service at the IdP
• If necessary, the IdP identifies the user (out of scope)
• The GET request includes a TARGET parameter
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 44
2
1
Identity Provider
Service Provider
Browser/Artifact Step 2• The IdP redirects to
the Assertion Consumer Service
• The redirect URL includes the TARGET parameter and a SAMLart parameter
• The artifact is a reference to an authN assertion
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 45
Browser/Artifact Step 1–2• Step 1 is identical to Browser/POST step 1• At step 2, the client is redirected to the
Assertion Consumer Service at the SP:HTTP/1.1 302 FoundLocation: https://sp.org/ACS/Artifact?TARGET=target&SAMLart=artifact
• The SAMLart value is an opaque reference to an assertion the IdP is willing to provide upon request
saml-v1_x-tech-overview-dec05 46
3
2
1
Identity Provider
Service Provider
Browser/Artifact Step 3• The user requests
the Assertion Consumer Service at the SP
• The request includes the TARGET and SAMLart parameters
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 47
Browser/Artifact Step 3• The client requests the Assertion
Consumer Service at the SP:https://sp.org/ACS/Artifact?TARGET=target&SAMLart=artifact
• An artifact encodes the following data:– 2-byte type code– 20-byte SourceID (usually IdP providerId)– 20-byte AssertionHandle
• Two artifact types are specified
saml-v1_x-tech-overview-dec05 48
4
3
2
1
Identity Provider
Service Provider
Browser/Artifact Step 4• The SP requests
the Artifact Resolution Service at the IdP via a mutually authenticated, back-channel exchange
• The SAML SOAP request includes the artifact
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 49
Browser/Artifact Step 4• The SP initiates a back-channel exchange
with the Artifact Resolution Service at the IdP• The following SAML query is bound to a
SAML SOAP request:<samlp:AssertionArtifact> artifact</samlp:AssertionArtifact>
• The artifact value was obtained from client previously
saml-v1_x-tech-overview-dec05 50
54
3
2
1
Identity Provider
Service Provider
Browser/Artifact Step 5• The IdP returns a
SAML Response to the SP
• The SAML Response contains an authentication assertion
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 51
6
54
3
2
1
Identity Provider
Service Provider
Browser/Artifact Step 6• The Assertion
Consumer Service validates the SAML Response element and creates a security context at the SP
• The SP redirects the client to the target resource
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 52
Browser/Artifact Step 5–6• The identity provider completes the
back-channel exchange by responding with a SAML assertion
• The assertion is similar to the one pushed by the client in Browser/POST (but without the signature)
• Step 6 is identical to Browser/POST step 4
saml-v1_x-tech-overview-dec05 53
7
6
54
3
2
1
Identity Provider
Service Provider
Browser/Artifact Step 7• The client
requests the protected resource
• This step is identical to Browser/POST step 5
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 54
8
7
6
54
3
2
1
Identity Provider
Service Provider
Browser/Artifact Step 8• The requested
resource is returned to the client
• This step is identical to Browser/POST step 6
CLIENT
AuthenticationAuthority
AttributeAuthority
Inter-siteTransferService
AssertionConsumer
Service
Resource
ArtifactResolution
Service
saml-v1_x-tech-overview-dec05 55
SAML Security• The security implications of the SAML
artifact profile have been critically examined:http://lists.oasis-open.org/archives/security-services/200406/msg00087.html
• The Security Services TC has responded:http://www.oasis-open.org/committees/download.php/13639/sstc-gross-sec-analysis-response-cd-01.pdf
saml-v1_x-tech-overview-dec05 57
Liberty Implementations• Implementations of Liberty ID-FF:
– SourceID ID-FF 1.2 Java Toolkit 2.0http://www.sourceid.org/projects/id-ff-1.2-java-toolkit.html
– Lassohttp://lasso.entrouvert.org/
– Proprietary vendor implementations
• Liberty ID-FF 1.2 is based on SAML 1.1• Since ID-FF was “donated” to OASIS
SAML, it is fair to say that ID-FF is a terminal specification