Transient Federations

This article covers how can OAM/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 is 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 is:

 <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:nameidformat: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-Dm0yBHekG6cejktwcKIFMzYE8Yrmqwfd0azz"
 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 results in a new transient NameID value being created.

Configuring OAM / IdP

The OAM server acting as an IdP supports the Transient NameID format, where the IdP issues an Assertion with a random transient value. This value is 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 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 Specifies the SP Partner Name
nameIDFormat Set to orafed-transient
nameIDValue Is left empty

An example is: setSPSAMLPartnerNameID("acmeSP", "orafedtransient")

Exit the WLST environment: exit().

After running this WLST command, IdP issues an Assertion with a Transient NameID format.

Configuring OAM/SP

Mapping the Incoming Assertion

In OAM 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, map an incoming SAML Assertion via a SAML Attribute. The Assertion contains issued by acmeIdP contains an attribute called username which is used 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-adminport/oamconsole.
Navigate to Federation , Service Provider Administration.
Create a new IdP Partner or edit an existing one.
In the Mapping section
1. Select Map assertion attribute to User ID Store attribute.
2. In this example, since we want to use the SAML Attribute called username, enter username as the Assertion Attribute.
3. In this example you map the username SAML Attribute to the LDAP uid attribute.
Click Save.

Description of the illustration SAML_Attr_Mapping.jpg

In this example, the Assertion issued by the IdP looks 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:nameidformat:transient">id-ev7P-H33gv6DQpGCQuwIXPEEGk-</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-Dm0yBHekG6cejktwcKIFMzYE8Yrmqwfd0azz"
 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 is:

Description of the illustration Federation_SSO.jpg

Mapping via a Static LDAP Account

It is possible to configure OAM/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 is mapped to the same LDAP account.

Since all the OAM sessions for different users are 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 OAM/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 raises the limit consequently.

To configure the IdP Partner entry so that OAM/SP maps 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-adminport/oamconsole.
Navigate to Federation , Service Provider Administration.
Create a new IdP Partner or edit an existing one.
In the Mapping section
1. Select Map assertion to user record using LDAP query
2. In this example, map the LDAP user record which has uid=userForAcmeIdP. As such, enter the LDAP query: (uid=userForAcmeIdP)
Click Save.

Description of the illustration Mapping_via_Static_LDAP_Account.jpg

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-adminport/oamconsole.
Navigate to Configuration , Common Settings.
Set the Maximum Number of Sessions per User setting, according to your requirements.
Click Apply.

Description of the illustration Common_Settings.jpg

We 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.com
sn: UserForAcmeIdP
uid: userForAcmeIdP

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

Description of the illustration Test_Federation_SSO.jpg

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.

Title and Copyright Information

Transient Federations

F61886-01

September 2022