[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Tech Overview outstanding issues
On 10/9/06, Eve L. Maler <Eve.Maler@sun.com> wrote:
>
> Tom Scavo has kindly offered to supply some code examples. It looks
> like he's just about done with a set, which I can include in the
> next rev.
Three text files are attached:
saml2-sso-redirect-post.txt
saml2-sso-redirect-artifact.txt
saml2-sso-artifact-artifact.txt
The first two correspond to sections 4.1.2 and 4.1.3, respectively.
The third example, which illustrates artifact resolution in both
directions, does not correspond to any subsection in section 4.1. It
is included as an interesting advanced case ("interesting" as in
"totally new in SAML V2.0").
For completeness, the code fragments are embedded in step-by-step
flows. Unfortunately, the steps in the above documents do not agree
with the steps in the Tech Overview. I believe the steps in the
attached documents are "correct", but if you disagree, simply cut the
code fragments and paste them into the appropriate spots in the Tech
Overview.
Hope this helps,
Tom Scavo
NCSA/University of Illinois
SAML V2.0 Web Browser SSO Profile
This is a possible deployment of the SAML V2.0 Web Browser SSO Profile where the service provider (SP) and the identity provider (IdP) use the HTTP Redirect and HTTP POST bindings, respectively. The message flow begins with a request for a secured resource at the SP.
1) Request the target resource at the SP
The client requests a target resource at the service provider:
https://sp.example.org/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2--7.
2) Redirect to the Single Sign-on (SSO) Service at the IdP
The service provider redirects the client to the Single Sign-on (SSO) Service at the identity provider. A RelayState parameter and a SAMLRequest parameter are appended to the redirect URL. The value of the SAMLRequest parameter is a URL-encoded string constructed from the following request:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="1">
<saml:Issuer>https://sp.example.org/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
Before the <samlp:AuthnRequest> element is URL-encoded and appended to the redirect URL, it is first deflated and base64-encoded (in that order).
3) Request the SSO Service at the IdP
The client requests the SSO service at the identity provider:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
where token is an opaque reference to state information maintained at the service provider and request is the encoded <samlp:AuthnRequest> element from step 2. The SSO service processes the AuthnRequest (by URL-decoding, base64-decoding and inflating, in that order) and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
4) Respond with an HTML form
The SSO service validates the request and responds with a document containing an HTML form:
<form method="post" action="https://sp.example.org/SAML2/SSO/POST"; ...>
<input type="hidden" name="SAMLResponse" value="response" />
<input type="hidden" name="RelayState" value="token" />
...
<input type="submit" value="Submit" />
</form>
The value of the RelayState parameter has been preserved from step 3. The value of the SAMLResponse parameter is the base64 encoding of the following <samlp:Response> element:
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.org/SAML2/SSO/POST";>
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<!-- a POSTed assertion MUST be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="identifier_1"
Recipient="https://sp.example.org/SAML2/SSO/POST";
NotOnOrAfter="2004-12-05T09:27:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.org/SAML2</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_3">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
5) Request the Assertion Consumer Service at the SP
The client issues a POST request to the assertion consumer service at the service provider:
POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=token
where the values of the SAMLResponse and RelayState parameters are taken from the HTML form at step 4.
6) Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the client to the target resource.
7) Request the target resource at the SP again
The client requests the target resource at the service provider (again):
https://sp.example.org/myresource
8) Respond with requested resource
Since a security context exists, the service provider returns the resource to the client.
SAML V2.0 Web Browser SSO Profile
This is a possible deployment of the SAML V2.0 Web Browser SSO Profile where the service provider (SP) and the identity provider (IdP) use the HTTP Redirect and HTTP Artifact bindings, respectively. The message flow begins with a request for a secured resource at the SP.
1) Request the target resource at the SP
The client requests a target resource at the service provider:
https://sp.example.org/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2--9.
2) Redirect to the Single Sign-on (SSO) Service at the IdP
The service provider redirects the client to the Single Sign-on (SSO) Service at the identity provider. A RelayState parameter and a SAMLRequest parameter are appended to the redirect URL. The value of the SAMLRequest parameter is a URL-encoded string constructed from the following request:
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
AssertionConsumerServiceIndex="1">
<saml:Issuer>https://sp.example.org/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
Before the <samlp:AuthnRequest> element is URL-encoded and appended to the redirect URL, it is first deflated and base64-encoded (in that order).
3) Request the SSO Service at the IdP
The client requests the SSO service at the identity provider:
https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=token
where token is an opaque reference to state information maintained at the service provider and request is the encoded <samlp:AuthnRequest> element from step 2. The SSO service processes the AuthnRequest (by URL-decoding, base64-decoding and inflating, in that order) and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
4) Redirect to the Assertion Consumer Service
The SSO service at the identity provider redirects the client to the assertion consumer service at the service provider. The previous RelayState parameter and a SAMLart parameter are appended to the redirect URL.
5) Request the Assertion Consumer Service at the SP
The client requests the assertion consumer service at the service provider:
https://sp.example.org/SAML2/SSO/Artifact?SAMLart=artifact&RelayState=token
where token is the token value from step 3 and artifact is the SAML artifact issued at step 4.
6) Request the Artifact Resolution Service at the IdP
The assertion consumer service dereferences the artifact by sending a SAML ArtifactResolve message to the artifact resolution service at the identity provider:
<samlp:ArtifactResolve
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_4"
Version="2.0"
IssueInstant="2004-12-05T09:22:04Z"
Destination="https://idp.example.org/SAML2/ArtifactResolution";>
<saml:Issuer>https://sp.example.org/SAML2</saml:Issuer>
<!-- an ArtifactResolve message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Artifact>artifact</samlp:Artifact>
</samlp:ArtifactResolve>
where the value of the <samlp:Artifact> element is the SAML artifact transmitted at step 5.
7) Respond with a SAML Assertion
The artifact resolution service at the identity provider returns a SAML ArtifactResponse message (containing an <samlp:Response> element) to the assertion consumer service at the service provider:
<samlp:ArtifactResponse
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="identifier_5"
InResponseTo="identifier_4"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<!-- an ArtifactResponse message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_6"
InResponseTo="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.org/SAML2/SSO/Artifact";>
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_7"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<!-- a Subject element is required -->
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@mail.idp.example.org
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="identifier_3"
Recipient="https://sp.example.org/SAML2/SSO/Artifact";
NotOnOrAfter="2004-12-05T09:27:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.org/SAML2</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_7">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
</samlp:ArtifactResponse>
8) Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the client to the target resource.
9) Request the target resource at the SP again
The client requests the target resource at the service provider (again):
https://sp.example.org/myresource
10) Respond with the requested resource
Since a security context exists, the service provider returns the resource to the client.
SAML V2.0 Web Browser SSO Profile
This is a possible deployment of the SAML V2.0 Web Browser SSO Profile where both the service provider (SP) and the identity provider (IdP) use the HTTP Artifact binding. The message flow begins with a request for a secured resource at the SP.
1) Request the target resource at the SP
The client requests a target resource at the service provider:
https://sp.example.org/myresource
The service provider performs a security check on behalf of the target resource. If a valid security context at the service provider already exists, skip steps 2--11.
2) Redirect to the Single Sign-on (SSO) Service at the IdP
The service provider redirects the client to the single sign-on (SSO) service at the identity provider. A RelayState parameter and a SAMLart parameter are appended to the redirect URL.
3) Request the SSO Service at the IdP
The client requests the SSO service at the identity provider:
https://idp.example.org/SAML2/SSO/Artifact?SAMLart=artifact&RelayState=token
where token is an opaque reference to state information maintained at the service provider and artifact is a SAML artifact, both issued at step 2.
4) Request the Artifact Resolution Service at the SP
The SSO service dereferences the artifact by sending a SAML ArtifactResolve message to the artifact resolution service at the service provider:
<samlp:ArtifactResolve
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:58Z"
Destination="https://sp.example.org/SAML2/ArtifactResolution";>
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<!-- an ArtifactResolve message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Artifact>artifact</samlp:Artifact>
</samlp:ArtifactResolve>
where the value of the <samlp:Artifact> element is the SAML artifact transmitted at step 3.
5) Respond with a SAML AuthnRequest
The artifact resolution service at the service provider returns a SAML ArtifactResponse message (containing an <samlp:AuthnRequest> element) to the SSO service at the identity provider:
<samlp:ArtifactResponse
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="identifier_2"
InResponseTo="identifier_1"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z">
<!-- an ArtifactResponse message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:21:59Z"
Destination="https://idp.example.org/SAML2/SSO/Artifact";
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
AssertionConsumerServiceURL="https://sp.example.org/SAML2/SSO/Artifact";>
<saml:Issuer>https://sp.example.org/SAML2</saml:Issuer>
<samlp:NameIDPolicy
AllowCreate="false"
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"/>
</samlp:AuthnRequest>
</samlp:ArtifactResponse>
The SSO service processes the AuthnRequest and performs a security check. If the user does not have a valid security context, the identity provider identifies the user (details omitted).
6) Redirect to the Assertion Consumer Service
The SSO service at the identity provider redirects the client to the assertion consumer service at the service provider. The previous RelayState parameter and a new SAMLart parameter are appended to the redirect URL.
7) Request the Assertion Consumer Service at the SP
The client requests the assertion consumer service at the service provider:
https://sp.example.org/SAML2/SSO/Artifact?SAMLart=artifact&RelayState=token
where token is the token value from step 3 and artifact is the SAML artifact issued at step 6.
8) Request the Artifact Resolution Service at the IdP
The assertion consumer service dereferences the artifact by sending a SAML ArtifactResolve message to the artifact resolution service at the identity provider:
<samlp:ArtifactResolve
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_4"
Version="2.0"
IssueInstant="2004-12-05T09:22:04Z"
Destination="https://idp.example.org/SAML2/ArtifactResolution";>
<saml:Issuer>https://sp.example.org/SAML2</saml:Issuer>
<!-- an ArtifactResolve message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Artifact>artifact</samlp:Artifact>
</samlp:ArtifactResolve>
where the value of the <samlp:Artifact> element is the SAML artifact transmitted at step 7.
9) Respond with a SAML Assertion
The artifact resolution service at the identity provider returns a SAML ArtifactResponse message (containing an <samlp:Response> element) to the assertion consumer service at the service provider:
<samlp:ArtifactResponse
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
ID="identifier_5"
InResponseTo="identifier_4"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<!-- an ArtifactResponse message SHOULD be signed -->
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<samlp:Response
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_6"
InResponseTo="identifier_3"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z"
Destination="https://sp.example.org/SAML2/SSO/Artifact";>
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>...</ds:Signature>
<samlp:Status>
<samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="identifier_7"
Version="2.0"
IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<!-- a Subject element is required -->
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
user@mail.idp.example.org
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="identifier_3"
Recipient="https://sp.example.org/SAML2/SSO/Artifact";
NotOnOrAfter="2004-12-05T09:27:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.org/SAML2</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="identifier_7">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</samlp:Response>
</samlp:ArtifactResponse>
10) Redirect to the target resource
The assertion consumer service processes the response, creates a security context at the service provider and redirects the client to the target resource.
11) Request the target resource at the SP again
The client requests the target resource at the service provider (again):
https://sp.example.org/myresource
12) Respond with the requested resource
Since a security context exists, the service provider returns the resource to the client.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]