Re: [security-services] Tech Overview outstanding issues

["Tom Scavo" <trscavo@gmail.com>]

On 9/29/06, Eve L. Maler <Eve.Maler@sun.com> wrote:
>
> Tom, thanks for offering a detailed code example!  I think an
> SP-initiated SSO flow would be most common and most welcome.  I
> might also reprise it somewhat in the introductory material, unless
> people think that having two examples for similar stuff that differ
> only in unimportant details is useful.

Attached is an SSO flow with hand-crafted example code.  Comments are welcome.

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.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:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:21:59Z"
    AssertionConsumerServiceIndex="1">
    <saml:Issuer>https://sp.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.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.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:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    ID="identifier_2"
    InResponseTo="identifier_1"
    Version="2.0"
    IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.org/SAML2/SSO/POST";>
    <saml:Issuer>https://idp.org/SAML2</saml:Issuer>
    <!-- a POSTed response MUST 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>
    <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.org/SAML2</saml:Issuer>
      <!-- a Subject element is required -->
      <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.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.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.

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.org/myresource

8) Respond with requested resource

Since a security context exists, the service provider returns the
resource to the client.