X

Tips and HowTos for Single Sign-On & Federation Oracle Identity Management Integrations

  • October 4, 2015

Transient Federations

In my previous article I discussed how to use a Federation Data Store to save/retrieve:

  • SAML 2.0 Persistent NameIDs
  • OpenID 2.0 NameIDs

As part of that article, I mentioned the SAML 2.0 Transient NameID format. In today's entry, I will cover how can OIF/OAM be configured to use SAML 2.0 Transient NameID format when acting as an IdP or as an SP.

Transient NameID Format


The SAML 2.0 specifications define the Transient NameID format as a NameID whose value will be a random identifier, unique for this Federation SSO operation and used only one time.

This is typically used in cases where the SP does not care to know who the user is, but only wishes to know that the user is a valid user at the IdP that was successfully authenticated.

If the user wants to know more information about the user via SAML Attributes contained in the SAML Assertion, then it does not really make sense to use the Transient NameID format.

An example of an Assertion issued by an IdP with an Transient NameID would be:

<samlp:Response ...>
    <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>https://idp.com/oam/fed</saml:Issuer>
        <dsig:Signature>
            ...
        </dsig:Signature>
        <saml:Subject>
<saml:NameID NameQualifier="https://idp.com/oam/fed" SPNameQualifier="https://acme.com/sp" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">id-U-2ajxWgNtPyLEv4NVz0Vsvuf7w-</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

                <saml:SubjectConfirmationData .../>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://acme.com/sp</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z" SessionIndex="id-6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz" SessionNotOnOrAfter="2014-03-21T21:53:55Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                     urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
    </saml:Assertion>
</samlp:Response>

A subsequent Federation SSO operation for the same user with the same IdP and SP would result in a new transient NameID value being created.

Configuring OIF / IdP


The OIF server acting as an IdP supports the Transient NameID format, where the IdP will issue an Assertion with a random transient value. This value will be randomly generated every time a Federation SSO occurs, even if the same user performs the Federation SSO operation once again with the same SP Partner.

To configure OIF/IdP to use Transient as the NameID format for a specific SP partner, perform the following steps:

  • Enter the WLST environment by executing:
    $IAM_ORACLE_HOME/common/bin/wlst.sh
  • Connect to the WLS Admin server:
    connect()
  • Navigate to the Domain Runtime branch:
    domainRuntime()
  • Execute the setSPSAMLPartnerNameID WLST command:
    setSPSAMLPartnerNameID(partnerName, nameIDFormat, nameIDValue="", customFormat="", nameIDValueComputed="false")
    • partnerName will be the SP Partner Name
    • nameIDFormat will be set to orafed-transient
    • nameIDValue will be left empty
    • An example would be:
      setSPSAMLPartnerNameID("acmeSP", "orafed-transient")
  • Exit the WLST environment:
    exit()

After executing this WLST command, OIF/IdP would issue an Assertion with a Transient NameID format.

Configuring OIF/SP


Mapping the Incoming Assertion

In OAM/OIF acting as an SP, the incoming Assertion must be mapped to an LDAP user account, as OAM requires an LDAP user in order to create an OAM session.

When mapping an incoming Assertion with a Transient NameID format, two choices are available:

  • Mapping the Assertion via SAML User Attributes (for example one of the SAML Attribute contains the userID or the user's email address)
  • Mapping the Assertion to a static LDAP account for that IdP (for example, mapping the Assertions coming from AcmeIdP to a user account called user-acmeIDP)

Mapping via SAML Attributes

In this example, I will map an incoming SAML Assertion via a SAML Attribute. The Assertion contains issued by acmeIdP contains an attribute called username which I will use to map the Assertion to a local user record. Perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Federation -> Service Provider Administration
  • Create a new IdP Partner or edit an existing one
  • In the Mapping section
    • Select "Map assertion attribute to User ID Store attribute"
    • In this example, since I want to use the SAML Attribute called username, I will enter username as the Assertion Attribute
    • In this example I will attempt to map the username SAML Attribute to the LDAP uid attribute
  • Save

In this example, the Assertion issued by the IdP would look like:

<samlp:Response ...>
    <saml:Issuer ...>https://acme.com/idp</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer ...>https://acme.com/idp</saml:Issuer>
        <dsig:Signature>
            ...
        </dsig:Signature>
        <saml:Subject>
<saml:NameID NameQualifier="https://acme.com/idp" SPNameQualifier="https://sso.com/oam/fed" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">id-ev7P-H33gv6DQpGCQuwIXP-EEGk-</saml:NameID>
            <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <saml:SubjectConfirmationData .../>
            </saml:SubjectConfirmation>
        </saml:Subject>
        <saml:Conditions ...>
            <saml:AudienceRestriction>
                <saml:Audience>https://sso.com/oam/fed</saml:Audience>
            </saml:AudienceRestriction>
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2014-03-21T20:53:55Z" SessionIndex="id-6i-Dm0yB-HekG6cejktwcKIFMzYE8Yrmqwfd0azz" SessionNotOnOrAfter="2014-03-21T21:53:55Z">
            <saml:AuthnContext>
                <saml:AuthnContextClassRef>
                      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
                </saml:AuthnContextClassRef>
            </saml:AuthnContext>
        </saml:AuthnStatement>
        <saml:AttributeStatement ...>
<saml:Attribute Name="username" ...>
                <saml:AttributeValue ...>alice</saml:AttributeValue>
            </saml:Attribute>

            <saml:Attribute Name="emailAddress" ...>
                <saml:AttributeValue ...>alice@oracle.com</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

And using the Test SP SSO application, the result would be:

Mapping via a Static LDAP Account

It is possible to configure OIF/SP to map all incoming Assertions from a specific IdP Partner to a static LDAP account: every incoming users with an assertion issued by that IdP partner would then be mapped to the same LDAP account.

Since all the OAM sessions for different users will be created for the same LDAP account, there might be a problem where OAM raises an error due to the maximum number of sessions for the same user being reached: indeed, OAM ensures at runtime that a specific LDAP user account cannot have more than the maximum number of sessions set by the OAM administrator.

Currently, when configuring OIF/SP to map all incoming Assertions from a specific IdP Partner to a static LDAP account, there is no capability to bypass the OAM maximum number of session per user feature. The OAM administrator will have to raise the limit consequently.

To configure the IdP Partner entry so that OIF/SP will map all incoming Assertions to the same static LDAP account, perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Federation -> Service Provider Administration
  • Create a new IdP Partner or edit an existing one
  • In the Mapping section
    • Select "Map assertion to user record using LDAP query"
    • In this example, I will map to the LDAP user record which has uid=userForAcmeIdP. As such, I will enter the LDAP query: (uid=userForAcmeIdP)
  • Save

To configure Maximum Number of Sessions per User in , perform the following steps:

  • Go to the OAM Administration Console: http(s)://oam-admin-host:oam-admin-port/oamconsole
  • Navigate to Configuration -> Common Settings
  • Set the Maximum Number of Sessions per User setting, according to your requirements
  • Apply

I created a user called userForAcmeIdP in the LDAP directory, based on the LDIF data:

version: 1
DN: cn=userForAcmeIdP,ou=users,dc=us,dc=oracle,dc=com
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: top
cn: userForAcmeIdP
givenName: UserForAcmeIdP
mail: userForAcmeIdP@oracle.comsn: UserForAcmeIdP
uid: userForAcmeIdP

Using the Test SP SSO application to perform a Federation SSO operation, the result would be:

In my next article, I will cover how to integrate Google IdP with OIF SP.
Cheers,
Damien Carru

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.