Transcript SAML Overview - Grid Computing at NCSA

Security Assertion
Markup Language
SAML 1.x Technical Overview
Tom Scavo
[email protected]
NCSA
saml-v1_x-tech-overview-dec05
1
SAML 1.0
saml-v1_x-tech-overview-dec05
2
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 EAuthentication Initiative has adopted
SAML 1.0 as its core technology
saml-v1_x-tech-overview-dec05
3
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
4
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
5
SAML 1.1 Basics
saml-v1_x-tech-overview-dec05
6
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
7
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
8
SAML 1.1 Schema
• SAML uses XML Schema as the
specification language
• Assertion Schema
http://www.oasis-open.org/committees/download.php/3408/oasis-sstc-saml-schema-assertion-1.1.xsd
• Protocol Schema
http://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
9
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
10
SAML 1.1 Core
saml-v1_x-tech-overview-dec05
11
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
12
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
13
SAML 1.1 Statements
• SAML 1.1 statement syntax:
– <AuthenticationStatement>
– <AttributeStatement>
– <AuthorizationDecisionStatement>
saml-v1_x-tech-overview-dec05
14
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
15
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
16
Authentication Method
• SAML 1.1 specifies numerous (11)
AuthenticationMethod identifiers:
urn:oasis:names:tc:SAML:1.0:am:password
urn:ietf:rfc:1510 (i.e., Kerberos)
urn:oasis:names:tc:SAML:1.0:am:X509-PKI
urn:oasis:names:tc:SAML:1.0:am:unspecified
etc.
• These identifiers describe (to an SP) an
authentication act that occurred in the past
• SAML2 extends this notion…
saml-v1_x-tech-overview-dec05
17
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
18
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 gridbased authz callout:
http://users.sdsc.edu/~chandras/Papers/ccgrid-submission.pdf
saml-v1_x-tech-overview-dec05
19
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
20
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
21
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
22
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
23
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
24
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
25
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
26
SAML 1.1
Bindings and Profiles
saml-v1_x-tech-overview-dec05
27
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
28
SAML 1.1 Profiles
• SAML 1.1 specifies two profiles:
– Browser/POST Profile
– Browser/Artifact Profile
• These browser profiles are crossdomain single sign-on (SSO) profiles
• No other profiles are specified in this
version of SAML
saml-v1_x-tech-overview-dec05
29
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
30
Browser/POST Profile
• The client handcarries an
authentication
assertion from the
IdP to SP
• We assume the
client has already
authenticated and
possesses a
security context at
the IdP
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
2
3
4
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
5
Resource
6
Service Provider
saml-v1_x-tech-overview-dec05
31
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)
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
32
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
33
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
saml-v1_x-tech-overview-dec05
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
2
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
Resource
Service Provider
34
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
35
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
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
2
3
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
36
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
37
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
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
2
3
4
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
38
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
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
2
3
4
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
5
Resource
Service Provider
saml-v1_x-tech-overview-dec05
39
Browser/POST Step 6
• Since the client
possesses the
necessary
security context,
access is
allowed
• The requested
resource is
returned to the
client
Identity Provider
Authentication
Authority
1
C
L
I
E
N
T
2
3
4
Inter-site
Transfer
Service
Attribute
Authority
Assertion
Consumer
Service
5
Resource
6
Service Provider
saml-v1_x-tech-overview-dec05
40
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 IdPfirst for simplicity
• SP-first profiles introduce some
complex issues (such as IdP Discovery)
saml-v1_x-tech-overview-dec05
41
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
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
4
3
6
5
Assertion
Consumer
Service
7
Resource
8
Service Provider
saml-v1_x-tech-overview-dec05
42
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
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
43
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
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
44
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 Found
Location:
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
45
Browser/Artifact Step 3
• The user requests
the Assertion
Consumer Service
at the SP
• The request
includes the
TARGET and
SAMLart
parameters
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
3
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
46
Browser/Artifact Step 3
• The client requests the Assertion
Consumer Service at the SP:
https://sp.org/ACS/Artifact?T
ARGET=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
47
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
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
4
3
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
48
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
49
Browser/Artifact Step 5
• The IdP returns a
SAML Response to
the SP
• The SAML
Response contains
an authentication
assertion
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
4
3
5
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
50
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
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
4
3
6
5
Assertion
Consumer
Service
Resource
Service Provider
saml-v1_x-tech-overview-dec05
51
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
52
Browser/Artifact Step 7
• The client
requests the
protected
resource
• This step is
identical to
Browser/POST
step 5
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
4
3
6
5
Assertion
Consumer
Service
7
Resource
Service Provider
saml-v1_x-tech-overview-dec05
53
Browser/Artifact Step 8
• The requested
resource is
returned to the
client
• This step is
identical to
Browser/POST
step 6
Identity Provider
1
C
L
I
E
N
T
Authentication
Authority
Attribute
Authority
Inter-site
Transfer
Service
Artifact
Resolution
Service
2
4
3
6
5
Assertion
Consumer
Service
7
Resource
8
Service Provider
saml-v1_x-tech-overview-dec05
54
SAML Security
• The security implications of the SAML
artifact profile have been critically
examined:
http://lists.oasis-open.org/archives/securityservices/200406/msg00087.html
• The Security Services TC has responded:
http://www.oasisopen.org/committees/download.php/1363
9/sstc-gross-sec-analysis-response-cd01.pdf
saml-v1_x-tech-overview-dec05
55
Misc
saml-v1_x-tech-overview-dec05
56
Liberty Implementations
• Implementations of Liberty ID-FF:
– SourceID ID-FF 1.2 Java Toolkit 2.0
http://www.sourceid.org/projects/id-ff-1.2-java-toolkit.html
– Lasso
http://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-dec05
57