- SAP Managed Tags:
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.
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.
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.
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.
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.
- Azure: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customi...
- AD FS: KBA 2945414 - 'SAML2Assertion does not specify Subject NameID' error with AD FS
- Okta: https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard_SAML.htm
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:
- Create a New User
- SCIM REST API
- Identity Provisioning (IPS)
- Import or Update Users for a Specific Application
- Import CSV File with Full User Profile
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.
19 Comments
