End users can hit possible issue when having to update manually the SAML nameID attributes sun-fm-saml2-nameid-infokey and sun-fm-saml2-nameid-info that were cached on user Forgerock DJ profile
For the XYZ application, the customer mapped attribute1 for the NameID Value Map(i.e. urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=attribute1) on SAML IdP NameID Format configuration.
Due to a new requirement they had to switch the “Name ID” from attribute1 to attribute2 the customer modified NameID Value mapping in IdP configuration from "attribute1"(i.e. urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=attribute1) to "attribute2"(i.e. urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified=attribute2).
Due to this change the customer ran into issue in Production where users were unable to federate to the application and SAML SSO to application failed. They troubleshooted and found that SAML nameID attributes "sun-fm-saml2-nameid-info" and "sun-fm-saml2-nameid-infokey" were cached/persisted on user Forgerock DJ profile with "attribute1" values and SAML Federation was using those cached/persisted values and preventing user login to the service provider(SP).
As a workaround they had to manually clear those persisted/cached NameID Value mapped attributes("sun-fm-saml2-nameid-info" and "sun-fm-saml2-nameid-infokey") for the application. It was a tedious task for the customer to clear those persisted/cached NameID Value mapped attributes manually for 350K users in Production.
Export the data to ldif excluding the sun-fm-saml2-nameid-infokey and sun-fm-saml2-nameid-info
This will remove these values for all entries in the DS server. You will then import the data back into the server:
This will force the users to re-establish their saml information.
The export and import solution described above may be OK for a Test environment, however the customer believes that it wouldn't be an ideal solution on PROD instance with 350K+ user base. There could be chances of risk in corrupting user data for any reason the import fails or something else would go wrong.
They are looking for an alternate configuration option/solution where the persisted data gets automatically updated when such NameID value mapping in the SAML configuration is updated.
Forgerock AM should be able to update the SAML mapping entries (sun-fm-saml2-nameid-infokey and sun-fm-saml2-nameid-info) in the DJ whenever the user login/authenticate(SAML SSO) after that NameID value mapping update.