Skip to Content
Technical Articles
Author's profile photo Istvan Bokor

Options to manipulate the subject name ID coming from the corporate IdP in proxy scenarios

In this blog post, I will show you what options are available in case you are using Identity Authentication as a proxy and you want to modify the subject name ID (let’s say attribute A) that you got from the corporate IdP (e.g. Azure, Okta, AD FS, etc.) to attribute B which will be sent to the application (e.g. SuccessFactors, IBP, S/4Hana Cloud, etc.).

As an example, you have Azure as an IdP, which is sending e-mail attribute as subject name ID, however on the S/4Hana Cloud side or on the IBP side, it is expecting the exact same value that is set as user name for the business users. Since on the S/4Hana Cloud side or on the IBP side the user name cannot contain the ‘@’ symbol, the login will not work, and you will see the S/4Hana Cloud/IBP login page instead of logging in successfully after you have provided your credentials.

So in the above example proxy scenario, this is the situation:

The corporate IdP is sending e-mail as subject name ID, it redirects it with assertion attributes to Identity Authentication, which is forwarding the e-mail subject name ID and the assertion attributes to the Service Provider (SP). Since the SP expects username (tuser in our example), and something@e-mail.com does not match to tuser, the login fails.

Our goal will be in this blog post, to resolve the above problem. I will show you three options to overcome this.

DISCLAIMER: I use dummy attribute technical names in the examples, always ensure about the exact attribute name of yours – my values are only for demonstrating purpose.

Option 1: Change the subject name ID on the corporate IdP side

The easiest way is to change the subject name ID on your corporate IdP side: instead of the e-mail, configure it to send the expected attribute instead. Use an existing attribute that will hold the exact same value that SP expects, or create such an attribute and set it as the name ID:

To add an attribute on the corporate IdP side, or to learn how you can change which attribute to send from the corporate IdP as the subject name ID, consult its vendor’s documentation.

In case this option is not favorable for you, check option 2 or option 3 below.

Option 2: Transform the received assertion attribute to be sent as subject name ID

In option 2, the subject name ID can be the default one, coming from the corporate IdP (for example e-mail), but you need to ensure, that among the assertion attributes the expected attribute is also present as the screenshot below:

In this example, let’s assume that you have created an attribute with the technical name ‘uname’ which holds exactly the same value (in our example ‘tuser’) that is the expected value on the destination.

I.) On Identity Authentication Administration Console go to: Applications & Resources > Applications > <app> > Subject Name Identifier > Advanced Configuration:
Dynamic subject name identifier value: ${corporateIdP.uname}
Select a fallback attribute: Login Name

See: Configure the Subject Name Identifier Sent to the Application.

II.) Then, on Identity Authentication Administration Console go to: Identity Providers > Corporate Identity Providers > <IdP> > Identity Federation > turn ON: Use Identity Authentication user store. Don’t worry, using this option the users DON’T have to exist on the Identity Authentication side – it just enables to use and take effect the advanced configuration settings!

See: Configure Identity Federation.

The Advanced Configuration will point out that instead of the subject name ID, which attribute should Identity Authentication forward as the subject name ID. The syntax is: ${corporateIdP.<corporateIDP attribute>}, where <corporateIDP attribute> is the attributes full technical name that holds the required value for the application.

III.) With this configuration, other attributes will not be sent to the application in assertion attributes. To send the other assertion attributes:
On Identity Authentication Administration Console go to: Applications & Resources > Applications > <app> > Default Attributes, and add Attribute:Value pairs:
fname:${corporateIdP.fname}
lname:${corporateIdP.lname}
mail:${corporateIdP.mail}

See: Configure the Default Attributes Sent to the Application.

Of course, use the names as it is configured on your corporate IdP, the above simple example is just for easier understanding. The exact names of the attributes are different on each identity provider, you can consult with the vendor’s documentation or you can get them from the SAML tracer.

To add an attribute on the corporate IdP side, or to learn how you can include it to be sent from the corporate IdP as an assertion attribute, consult its vendor’s documentation.

In case this option is not favorable for you, check option 3 below.

Option 3: Add users to Identity Authentication user store, and use Identity Federation

For selecting this option, the subject name ID can be the default one, coming from the corporate IdP (for example e-mail), but you need to ensure, that the same user with the same identifier (e-mail) is also present in the Identity Authentication user store as the screenshot below:

To provision (copy) the users to Identity Authentication, you can create users manually on Administration Console / use API / use Identity Provisioning (IPS) / use user import:

On Identity Authentication Administration Console go to: Identity Providers > Corporate Identity Providers > <IdP> > Identity Federation > turn ON: Use Identity Authentication user store AND Allow Identity Authentication users only.

See: Configure Identity Federation.

On Identity Authentication the application uses basic subject name ID configuration with Login Name attribute.

See: Configure the Subject Name Identifier Sent to the Application.

With this option, end-users will still see and authenticate through corporate IdP, but in the middle of the process Identity Authentication is doing the lookup, and since the user exists on Identity Authentication user store, the corresponding attributes will be taken to the application from the Identity Authentication, instead of from the corporate IdP (since the required attribute does exist only on Identity Authentication side, but not on corporate IdP side).


I hope the explanations above help you to decide which option to go on.

Assigned Tags

      10 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Yogananda Muthaiah
      Yogananda Muthaiah

      Well described Istvan Bokor !!

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Thank you, Yoga! 🙂

      Author's profile photo Sissy Haegele
      Sissy Haegele

      i miss the applause button! great blog that will help our customers and partners. thanks.

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Thank you, Sissy 🙂

      Author's profile photo Harjeet Judge
      Harjeet Judge

      Nice blog!

      Author's profile photo Ervin Szolke
      Ervin Szolke

      Great blog, Istvan!

      Author's profile photo James Reidy
      James Reidy

      Fantastic as always Istvan!

      Author's profile photo Krishna Gompa
      Krishna Gompa

      Istvan Bokor Excellent Blog helped us to fix our SSO.

      We are facing different error, after the IDP authentication is it taking us to page where we need to enter Compnay ID.  We are actually passing Company ID in SAML

       

      Could you please help us how to fix this error .

       

      Thanks

      Krishna

       

       

      Author's profile photo Istvan Bokor
      Istvan Bokor
      Blog Post Author

      Hello,

      To be able to help with this, I would need to check the SAML trace. You might open a support ticket for this issue.

      Best regards,
      István

      Author's profile photo Hadrien Paquet
      Hadrien Paquet

      Hi Istvan,

       

      Thank you for this explanation.  If I understand correctly there is no option for the IAS to identifiy the user from another other assertion attribute but the nameid in the SAML response of the corporate idp, is that correct ?

      Have ever faced the case where the Corporate IDP can't provide the unique identity in the nameid ?

      How can this be solved from the IAS ?

      thank you

      Hadrien