Saml-v1_x-tech-overview-dec051 Security Assertion Markup Language SAML 1.x Technical Overview Tom...

saml-v1_x-tech-overview-dec05 1

Security Assertion Markup Language

SAML 1.x Technical Overview

Tom [email protected]

NCSA


SAML 1.0


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

http://www.cio.gov/eauthentication/


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

http://www.cio.gov/eauthentication/


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

http://www.oasis-open.org/committees/download.php/3412/sstc-saml-diff-1.1-draft-01.pdf




SAML 1.1 Basics


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 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

http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf

http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf

http://www.oasis-open.org/committees/download.php/3404/oasis-sstc-saml-sec-consider-1.1.pdf

http://www.oasis-open.org/committees/download.php/3402/oasis-sstc-saml-conform-1.1.pdf

http://www.oasis-open.org/committees/download.php/3401/oasis-sstc-saml-glossary-1.1.pdf


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"

http://www.oasis-open.org/committees/download.php/3408/oasis-sstc-saml-schema-assertion-1.1.xsd


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 1.1 Core


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

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"/> </saml:Assertion>

• The value of the Issuer attribute is the unique identifier of the IdP


SAML 1.1 Statements• SAML 1.1 statement syntax:

– <AuthenticationStatement>– <AttributeStatement>– <AuthorizationDecisionStatement>


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


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


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…


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


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

http://users.sdsc.edu/~chandras/Papers/ccgrid-submission.pdf


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 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 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 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> </samlp:Response>

• In the pull case, the response is preceded by a request

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"> </samlp:Request>

• There are a handful of specified SAML queries and a couple of extension points to construct your own


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 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 1.1Bindings and Profiles


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 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 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


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


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


AttributeAuthority


AssertionConsumer

Service

Resource


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


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


AttributeAuthority


AssertionConsumer

Service

Resource


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


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


AttributeAuthority


AssertionConsumer

Service

Resource


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


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


AttributeAuthority


AssertionConsumer

Service

Resource


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


AttributeAuthority


AssertionConsumer

Service

Resource


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


AttributeAuthority


AssertionConsumer

Service

Resource


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)


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


AttributeAuthority


AssertionConsumer

Service

Resource

ArtifactResolution

Service


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


Misc


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

Saml-v1_x-tech-overview-dec051 Security Assertion Markup Language SAML 1.x Technical Overview Tom...

Documents

Transcript of Saml-v1_x-tech-overview-dec051 Security Assertion Markup Language SAML 1.x Technical Overview Tom...