B.6 Identity Provider Process Flow

The following illustration provides an example of an Identity Server automatically creating an authenticated session for the user at a trusted SAML service provider. PP indicates a Personal Profile Service as defined by the Liberty specification.

Figure B-1 SAML Service Provider Process Flow

  1. A user is logged in to the Identity Server at abc.com (the user’s identity provider) and clicks a link to xyz.com, a trusted SAML service provider.

    The Identity Server at abc.com generates the artifact. This starts the process of generating and sending the SAML assertion. The HREF would look similar to the following:

    http://nidp.com/saml/genafct?TARGET=http://xyz.com/index.html&AID=XYZ

  2. The Identity Server processes attributes as follows:

    1. The server looks up LDAP or Liberty-LDAP mapped attributes. (See Section 15.6, Mapping LDAP and Liberty Attributes.) In this example, you use Liberty attributes such as PP: sn instead of surname. PP: sn and PP: ph# are attributes that you are sending to xyz.com.

    2. The Identity Server processes these attributes with a SAML implementation-specific attribute.

      Because the identity provider must interoperate with other SAML service providers that probably do not use consistent attribute names, you can map the service provider attributes to your Liberty and LDAP attributes on the Identity Server. In this example, the service provider names for the Liberty PP: sn and PP: ph# attributes are lastname and phonenumber, respectively. (See Section 7.6.1, Configuring the Attributes Obtained at Authentication.)

    3. The Identity Server uses the PP service to look up the values for the user’s PP: sn and PP: ph# attributes.

      The Identity Server recognizes that the values for the user’s PP: sn and PP: ph# attributes are Jones and 555-1212, respectively.

  3. The Identity Server sends an HTTP redirect with an artifact.

    The Identity Server now has the information to generate a SAML assertion. The Identity Server sends an HTTP redirect containing the artifact back to the browser. The redirect looks similar to the following: 

    http://xyz.com/auth/afct?TARGET=http://xyz.com/index.html&SAMLArtifact =<<artifact>>

  4. The remote SAML server requests the assertion.

    The HTTP redirect results in the browser sending the artifact to the SAML server at xyz.com. The SAML server at xyz.com requests the SAML assertion from the Identity Server.

  5. The Identity Server sends the assertion to the remote SAML server.

    The remote SAML server receives the artifact and looks up the assertion.The assertion is sent to the SAML server at xyz.com in a SOAP envelope. The assertion contains the attributes lastname=Jones and phonenumber=555-1212.

    The user now has an authenticated session at xyz.com. The xyz.com SAML server redirects the user’s browser to http://xyz.com/index.html, which was referenced in the original HREF in Step 1.