Identity Provider Process Flow

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

Figure 5-11 SAML Service Provider Process Flow

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

    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. Identity Server processes attributes as follows:

    1. The server looks up for LDAP or Liberty-LDAP mapped attributes. (See 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. 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 Identity Server. In this example, the service provider names for the Liberty PP: sn and PP: ph# attributes are lastname and phonenumber, respectively. (See Configuring the Attributes Obtained at Authentication.)

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

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

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

    Identity Server now has the information to generate a SAML assertion. Identity Server sends an HTTP redirect containing the artifact 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 Identity Server.

  5. 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 that was referenced in the original HREF in Step 1.