What identifier does IAS use from Azure when IAS is the user store

[StephenBurns]

In the IAS settings for the corporate identity provider, it says:

Switch on to use the data from Identity Authentication user store and send Subject Name Identifier (Name ID for SAML2.0 or Subject for OpenID Connect), assertion and default attributes according to the application configuration. For users with no profile in Identity Authentication, the application receives the subject name identifier from the corporate IdP assertion and attributes according to the application configuration.

How does IAS determine if a user has a profile within IAS or not?

I have a user with a profile in IAS, but their SAML trace still has the name ID that Azure sent, instead of the one in IAS

[sushilgupta857]

Hi Stephen,

When you enable identity fedration option in corporate idp, once authentication is complete in azure .. assertion is generated and sent to IAS..

now lets say user don’t exist in IAS then it will send the identifier and attributes received from IDP, If user exist then it will send the assertion and default attributes set in application in IAS.
IAS automatically checks if your profile exist or not.

Now if you want to change the identifier sent by IAS to the user application, then change it in subject name identifier in Applications tab in IAS.

Hope it helps ! Let me know your thoughts on this !

Regards

Sushil

[sushilgupta857]

now when you say , you have profile in IAS still it sent the attributes and identifier from azure , it may be because you may not have enabled identity fedration option. Both should be done - User should exist , identity fedration should be enabled to make it work.

Regards

[StephenBurns]

Thank you Sushil.

My question is specific to how IAS determines if the user exists. What information in the SAML response from Azure is used to match against IAS?

The SAML response has all of these Identity/Claims and Im not sure which one is used by IAS to identify existing users

[sushilgupta857]

Hi Stephan,
Subject name identifier and Assertion consumer URL.
Read more about these , you will get the understanding.

First one is used for mapping . User should exist in both IDP and application to make SSO work.

Assertion consumer url - tells which attributes are required by application from IDMS.

Other Attributes still don’t play that much role in authentication but can be used for other purposes like groups mapping with roles etc.

Try to test different scenarios by changing subject name identifier in IAS application tab , and you should get the understanding.
let me know if you are still confused.

There can by many scenarios which gets generated on multiple conditions and requirements.
usually IAS has the users so that it can perform the mapping and remove the restrictions of different applications supporting different identifiers.

Thanks and Regards

Sushil K Gupta

[Colt · Accepted solution]

Hey Stephen,

when combined with the "Use Identity Authentication user store" option, this allows end-users to continue using the corporate IdP for authentication. During the authentication process, the subject name ID sent from the corporate IdP in the first response to Identity Authentication Service (IAS) - usually the user's email address - is used to verify the existence of the user's profile in the SAP IAS user store, also known as the Identity Directory. SAP IAS then retrieves the required user attributes from its own user store and forwards them to the application for further processing.

This blog may answer your questions, happy reading!

Cheers Carsten

[StephenBurns · Accepted solution]

Thank you. I was hoping that I could have it use a different attribute than the subject name ID.

It seems as though it only uses subject name ID from the corporate IDP but looks for matches on more than just email

When Use Identity Authentication user store option is enabled, the application checks if the users authenticated by the corporate identity provider exist in the Identity Authentication user store. The existence check is done with the name identifier sent by the corporate identity provider for the identifying attributes uid, loginName, emails and phoneNumber.

Since you don't seem to be able to configure this matching, I wonder what would happen if someone had the same loginName as someone elses phone number or something like that, but i suppose thats pretty unlikely