OOTB, it uses uid as the mapping attribute. That works fine. However, we want to leverage another identity attribute. This other identity attribute, named ‘nameId’ essentially holds the same value as uid, and is searchable. However, when we select that identity attribute to be used as the Identity Mapping Attribute, that broke the SSO experience.
We’ve validated that the identity has the same uid and nameId value, matched casing between the two strings.
i.e.
Day 1: uid with unspecified, came back with persistent. Working, SSOed.
Day 2: Changed uid to nameId, with unspecified, came back with persistent. Not working.
Day 3: Changed back to uid with unspecified, came back with persistent. Not working.
For some reason, we’re not able to get that to work again even thought the configuration looks the same between Day 1 and Day 3, identity data has not changed on the uid attribute.
So the idp is not honouring the unspecified reqest by the sounds of it, it’s not obliged to. FWIK use of persistent is not normally used for correlation purposes as it is used to obfuscate the subject by createing a cached linkage between idp and sp, so changing config could potentially break it. Can you change the idp config to send unspecified?
Client’s SME on the IdP side seems hesitant to do so.
“so changing config could potentially break it”
No configuration change on the IdP end. Only on the SP side with regard to the Identity Attribute Mapping dropdown selection.
Tell him that persistent is used for SPs that can use claims for correlation, rather than subject name id. SailPoint requires correlation in SNI, so persistent not ideal.
