Version Affected: All
Overview
A SAML-integrated DocuSign realm can occasionally show the error "The Federated identifier for single sign-on does not match what has been enabled for this user" -- this happens most often when logging in through the DocuSign mobile app.
Cause
DocuSign stores the NameID as the user's Federated identifier the first time they log in, and this value is case-sensitive. If a user's username capitalization differs between logins -- for example, typing user1 in a browser, but a phone's keyboard automatically capitalizing it to User1 -- DocuSign throws this error because the login no longer matches the stored identifier.
Resolution:
The most reliable fix is to remove the human element entirely: change the realm's Post Authentication UserID Mapping to use the SamAccountName value from the datastore, instead of relying on what the user types.
- On the Data tab, pick an empty AuxID and set it to SamAccountName.
- On the Post Auth tab, set the UserID Mapping to the AuxID used in step 1.
This can also be solved using the Transformation Engine.
Special Considerations
Switching to this technique ensures the same Federated identifier is set every time, but that identifier may differ from what some users are already registered with in DocuSign. Those users need a one-time reset of their Federated identifier on the DocuSign side -- see DocuSign's KB article on resetting the Federated Identifier for the steps.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
0 comments
Please sign in to leave a comment.