Shibboleth Developers

[Tom Scavo <>]

Here are detailed examples of the shib browser/post and
browser/artifact profiles (as I understand them anyway).  Any comments
or corrections would be appreciated!

Shibboleth Browser/POST Profile

Here is a possible implementation of the Shibboleth Browser/POST Profile.

The message flow begins with a request for a secured resource at the SP.

1) The client requests a target resource at the SP:

  https://sp.com/myresource

The SP performs a security check on behalf of the target resource.  If
a valid security context at the SP already exists, skip steps 2--7.

2) The SP redirects the client to the single sign-on (SSO) service at
the IdP.  Three parameters are appended to the redirect URL.

3) The client requests the SSO service at the IdP:

  https://idp.com/shibboleth/SSO?providerId=id&shire=acs&target=target

  where     id = https://sp.com/shibboleth/
           acs = https://sp.com/shibboleth/SSO/POST
        target = https://sp.com/myresource

The SSO service processes the authn request and performs a security
check.  If the user does not have a valid security context, the IdP
identifies the principal (details omitted).

4) The SSO service responds with an HTML form:

  ...
  <form method="post" action="https://sp.com/shibboleth/SSO/POST"; ...>
    <input type="hidden" name="TARGET" value="target">
    <input type="hidden" name="SAMLResponse" value="response">
    ...
    <input type="submit" value="Submit">
  </form>
  ...

where the value of the TARGET parameter has been preserved from step
3.  The value of the SAMLResponse parameter is the base64 encoding of
a SAML Response element:

  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
    MajorVersion="1" MinorVersion="1"
    Recipient="https://sp.com/shibboleth/SSO/POST";
    ResponseID="..."
    IssueInstant="...">
    <ds:Signature 
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>
      <ds:SignedInfo>...</ds:SignedInfo>
      <ds:SignatureValue>...</ds:SignatureValue>
      <ds:KeyInfo>...</ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
      <samlp:StatusCode Value="samlp:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
      MajorVersion="1" MinorVersion="1"
      AssertionID="..."
      Issuer="https://idp.com/shibboleth/";
      IssueInstant="...">
      <saml:Conditions 
        NotBefore="..." 
        NotOnOrAfter="...">
        <saml:AudienceRestrictionCondition>
          <saml:Audience>
            https://sp.com/shibboleth/
          </saml:Audience>
        </saml:AudienceRestrictionCondition>
      </saml:Conditions>
      <saml:AuthenticationStatement
        AuthenticationInstant="..."
        AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
        <saml:Subject>
          <saml:NameIdentifier 
            NameQualifier="https://idp.com/shibboleth/";
            Format="urn:mace:shibboleth:1.0:nameIdentifier">
            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>
    </saml:Assertion>
  </samlp:Response>

Note that the SAML Response must be digitally signed by the identity provider.

5) The client issues a POST request to the assertion consumer service
at the service provider.  To automate the submission of the form, the
following line of JavaScript may appear anywhere on the page:

  window.onload = function() { document.forms[0].submit(); }

This assumes of course that the page contains a single FORM element.

6) The assertion consumer service processes the authn response,
creates a security context at the SP and redirects the client to the
target resource.

7) The client requests the target resource at the SP (again):

  https://sp.com/myresource

8) Since a security context exists, the SP returns the resource to the client.

Issues:
- How does the SP know the client's preferred IdP at step 2? (WAYF, e.g.)
- Does the IdP send a providerId parameter at step 4?


Shibboleth Browser/Artifact Profile

Here is a possible implementation of the Shibboleth Browser/Artifact Profile.

The message flow begins with a request for a secured resource at the SP.

1) The client requests a target resource at the SP:

  https://sp.com/myresource

The SP performs a security check on behalf of the target resource.  If
a valid security context at the SP already exists, skip steps 2--9.

2) The SP redirects the client to the single sign-on (SSO) service at
the IdP.  Three parameters are appended to the redirect URL.

3) The client requests the SSO service at the IdP:

  https://idp.com/shibboleth/SSO?providerId=id&shire=acs&target=target

  where     id = https://sp.com/shibboleth/
           acs = https://sp.com/shibboleth/SSO/Artifact
        target = https://sp.com/myresource

The SSO service processes the authn request and performs a security
check.  If the user does not have a valid security context, the IdP
identifies the principal (details omitted).

4) The SSO service redirects the client to the assertion consumer
service at the SP.  A TARGET parameter and a SAMLart parameter are
appended to the redirect URL.

5) The client requests the assertion consumer service at the SP:

  https://sp.com/shibboleth/SSO/Artifact?TARGET=target&SAMLart=artifact

where the value of the TARGET parameter is preserved from step 3 and
the artifact is a SAML artifact.

6) The assertion consumer service dereferences the artifact by sending
a SAML Request to the artifact resolution service at the IdP:

  <samlp:Request 
    xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol" 
    MajorVersion="1" MinorVersion="1" 
    RequestID="..." 
    IssueInstant="...">
    <samlp:AssertionArtifact>
      artifact
    </samlp:AssertionArtifact>
  </samlp:Request>

where artifact is the SAML artifact at step 5.

7) The artifact resolution service at the IdP returns a SAML Response
(containing an authn assertion) to the assertion consumer service at
the SP:

  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol"
    MajorVersion="1" MinorVersion="1"
    Recipient="https://sp.com/shibboleth/SSO/POST";
    ResponseID="..."
    InResponseTo="..."
    IssueInstant="...">
    <samlp:Status>
      <samlp:StatusCode Value="samlp:Success"/>
    </samlp:Status>
    <saml:Assertion
      xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
      MajorVersion="1" MinorVersion="1"
      AssertionID="..."
      Issuer="https://idp.com/shibboleth/";
      IssueInstant="...">
      <saml:Conditions 
        NotBefore="..."
        NotOnOrAfter="..."/>
      <saml:AuthenticationStatement
        AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
        AuthenticationInstant="...">
        <saml:Subject>
          <saml:NameIdentifier 
            NameQualifier="https://idp.com/shibboleth/";
            Format="urn:mace:shibboleth:1.0:nameIdentifier">
            3F7B3DCF-1674-4ecd-92C8-1544F346BAF8
          </saml:NameIdentifier>
          <saml:SubjectConfirmation>
            <saml:ConfirmationMethod>
              urn:oasis:names:tc:SAML:1.0:cm:artifact
            </saml:ConfirmationMethod>
          </saml:SubjectConfirmation>
        </saml:Subject>
      </saml:AuthenticationStatement>
    </saml:Assertion>
  </samlp:Response>

8) The assertion consumer service processes the authn response,
creates a security context at the SP and redirects the client to the
target resource.

9) The client requests the target resource at the SP (again):

  https://sp.com/myresource

10) Since a security context exists, the SP returns the resource to the 
client.

Issues:
- How does the SP know the client's preferred IdP at step 2? (WAYF, e.g.)
- Does the IdP send a providerId parameter at step 4?
- Does the IdP send the URI of its artifact resolution service at step
4?  If so, what is the name of the corresponding parameter?
- What is the format of the artifact at step 5?