We are currently using Okta as the SAML/SSO provider for our SailPoint IdentityNow environment. However, we’ve recently started encountering the following error during login: “SAML assertion failed – contact your administrator.”
We’re looking for guidance on how to troubleshoot and resolve this issue. Any insights or suggestions would be appreciated.
are you seeing any errors in logs?
Hi @abraham0007 A good starting point is to add a SAML tracer to development tools in browser of your choice, and then examine the assertion. First thing to check is NameID and that it can correlate with the ISC Identity attribute configured for correlation of assertion to Identity. If it’s happening for all, check the signing certificate(s).
1 Like
got it let me check this constructive suggestion. and important thing is it was working till yesterday.
We have reviewed the logs and are not seeing any related errors at this time.
If it’s happening for all, then I strongly recommend examining (re-importing) the okta signing certificate. (I’m assuming that assertions aren’t encrypted).
After further investigation, we have observed that the issue is affecting only a specific group of users, not all users.
Ah, then examine the assertion as mentioned above. Admittedly, you probably can’t spoof a failure scenario, but check what value is in NameID and what it correlates to in ISC.
Oh one more question: Is this IdP or SP originated SSO? ie do users follow a link from Okta or go directly to ISC
can you see the events of those users what might have changed recently or any errors.
The SSO is configured as a Service Provider (SP) within the ISC under Global Settings.
Are you referring to the NameID attribute? If so, are you asking whether it maps to the account name? am not getting what is this nameid
Agreed that ISC is the SP, I was asking whether people go directly to the ISC URL, or click on a link in Okta?
Have you been able to examine the SAML assertion?
Yes, we have examined the SAML assertion and everything appears to be in good. When accessing the SailPoint link, it correctly redirects to Okta for SSO, and after successful authentication, it navigates back to the SailPoint ISC as expected.
Thanks, that is SP originated SSO. I was just checking whether the users who are getting a problem are using the link published in Okta (IdP originated SSO).
I noticed recent events showing both ‘Authentication Failed’ and ‘Account Created in Source’
Have you enabled JIT provisioning of identities?
can you check what is the type of source and its importance and why they created/reason?
I’m not sure about this—could it be temporary access?