Announcing the Saviynt Knowledge Exchange unifying the Saviynt forums, documentation, training,
and more in a single search tool across platforms. Read the announcement here.

SAML 2.0 failures due to not finding a username with that password

Robbe_Cronos
Regular Contributor II
Regular Contributor II

Hello,

We are trying to setup SAML2.0 on our environment and have managed to get redirected to our keycloak instance through the login page. However, when the authentication redirect happens and it tries to log us in through Keycloak, we get this error on the Saviynt page.

Robbe_Cronos_1-1675756808909.png

We are kind of confused about this error seeing as we don't use a password with SAML2.0.

We use "username" as the condition for assertion & our users in Keycloak and Saviynt have the same exact username (Case sensitive). Here are some logs for this error:

"ecm","2023-02-06T09:13:24.779+0000","{"log":"2023-02-06 09:13:24,772 [http-nio-8080-exec-2] DEBUG auth.LoginController - thresholdcount...3\n","stream":"stdout","time":"2023-02-06T09:13:24.773142645Z"}"
"ecm","2023-02-06T09:13:24.779+0000","{"log":"2023-02-06 09:13:24,774 [http-nio-8080-exec-2] DEBUG auth.LoginController - Before failed tries entry of user...null\n","stream":"stdout","time":"2023-02-06T09:13:24.774618376Z"}"
"ecm","2023-02-06T09:13:24.779+0000","{"log":"2023-02-06 09:13:24,774 [http-nio-8080-exec-2] DEBUG security.LoginService - start to update failed login entries....\n","stream":"stdout","time":"2023-02-06T09:13:24.774689405Z"}"
"ecm","2023-02-06T09:13:24.779+0000","{"log":"2023-02-06 09:13:24,775 [http-nio-8080-exec-2] DEBUG security.LoginService - end of update failed login entries....\n","stream":"stdout","time":"2023-02-06T09:13:24.775848409Z"}"
"ecm","2023-02-06T09:13:24.779+0000","{"log":"2023-02-06 09:13:24,776 [http-nio-8080-exec-2] DEBUG auth.LoginController - Entered password is valid...false\n","stream":"stdout","time":"2023-02-06T09:13:24.776140657Z"}"

Anyone know what could be going wrong here?

 

4 REPLIES 4

RakeshMG
Saviynt Employee
Saviynt Employee

Please validate the value for "grails.plugin.springsecurity.saml.disableinresponseToFieldCheck".

Refer following document for more details on above mentioned attribute - https://docs.saviyntcloud.com/bundle/EIC-Admin-v2021x/page/Content/Chapter06-EIC-Configurations/SAML...

Also following document has details about configuring SSO - https://docs.saviyntcloud.com/bundle/SSM-Admin-v55x/page/Content/Chapter06-Configuring-SSM/Configuri...

Few of the troubleshooting scenario - https://docs.saviyntcloud.com/bundle/SSM-Admin-v55x/page/Content/Chapter06-Configuring-SSM/Troublesh...


​Regards

Rakesh M Goudar

alanbixby
New Contributor III
New Contributor III

I'm not OP, but my team has been encountering this issue for a while too, we are using Azure AD SSO for our IdP.

As an additional data point, we currently have disableinresponseToFieldCheck = true, (currently encountering this error).

Clearing the SAML token cookie on the IdP / using incognito / an alternate browser was our original support ticket response to this issue; we have a new ticket up for this for attempt #2.

--

To caution against a potential rabbit hole; we usually would encounter this on the first login of the day / coming back from the weekend. There is a similar Freshdesk ticket that was resolved by bumping maxAuthenticationAge; we've set it significantly higher (8 hours), lower (15 minutes), and equal to the session length on our IdP (1 hour) with no luck.  There still conflicting documentation on what this is supposed to be; with tech leads stating is must be an exact match. (So nobody knows!) YMMV.

Another thing; when these errors happen we are able to see successful sign-in logs from the IdP that match up with the Saviynt application log timestamps, which add further confusion to the "can't find a user" error.

Hope this helps. Best of luck.
Please follow-up if your org finds a solution.

Robbe_Cronos
Regular Contributor II
Regular Contributor II

We have fixed the errors we encountered after a lot of trial and error. 

What we fixed: 

1. We switched from using the Keycloak Metadata file to filling in the sample IdP file from Saviynt with the values from the Keycloak Metadata file. Apparently, if you don't use the sample IdP file and sample SP file from Saviynt, it will give an error on syntax issues. 

2. Use the certificate of the generated keypair in the keystore you created as the certificate of the Metadata_SP file. 

3. Make sure the entityID is 100% correct everywhere you use it. We had an issue where we used it in Lowercase (saviyntsso) in all of our configurations, but the redirect URL on Keycloak had 'SAVIYNTSSO' in the URL. 

Hope this helps!

alanbixby
New Contributor III
New Contributor III

Thanks for the info.

Was your org having this error across the board, or was it intermittent (able to workaround with incognito, some days doesn't occur at all)? We are in latter camp which is what is making the troubleshooting so tedious. 

I did notice our config was using Azure AD's native metadata XML and not Saviynt's template, it only had urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified listed, so maybe that is the fundamental cause? I upgraded the configs and am crossing my fingers.

EDIT: It did not resolve our issue.