inception-project
SAML auth - Login with SSO service failed
Describe the bug When you try to log in with SAML authentication, there is an error message:
Login with SSO service failed. You might try logging out of your SSO service before trying to log in here again.
The following lines appear in the application.log file after a failed login:
WARN [SYSTEM] AbstractSubjectConfirmationValidator - Valid InResponseTo was not available from the validation context, unable to evaluate SubjectConfirmationData@InResponseTo
DEBUG [SYSTEM] BaseOpenSamlAuthenticationProvider - Found 2 validation errors in SAML response [_27465f7e-921a-46b9-a3e5-202e23f2a814]
DEBUG [SYSTEM] ProviderManager - Authentication failed with provider OpenSaml4AuthenticationProvider since The response contained an InResponseTo attribute [ARQ7297191-1e69-4c4b-aa4e-c11d12e59ac7] but no saved authentication request was found
To Reproduce Steps to reproduce the behavior:
- Go to the INCEpTION login screen.
- You should see a message "Log in using a SAML 2.0 identity provider". There is a button under this message with the label "inception-client". Click on the inception-client button.
Expected behavior The user should get authenticated by the IdP and then automatically logged in to INCEpTION.
Screenshots
Please complete the following information:
- Version 38.5
- Browser: Chrome, Firefox
Additional context
This issue is similar to the following issue:
https://github.com/spring-projects/spring-security/issues/17631
SAML authentication is working for us in INCEpTION version 33 with Spring Boot 2.7, but not in later INCEpTION versions with Spring Boot 3.x.
Authentication failed with provider OpenSaml4AuthenticationProvider since The response contained an InResponseTo attribute [ARQ7297191-1e69-4c4b-aa4e-c11d12e59ac7] but no saved authentication request was found
This typically happens when the identity provider sends back the wrong token - e.g. when you have multiple redirections in the IdP process like INCEpTION -> Keycloak -> Third Service and the Third Service sends its token back directly to INCEpTION instead of Keycloak. Maybe you can explain your setup?
We have inception-client as an SP and Azure AD as an IdP.
When using INCEpTION 33.2 and INCEpTION 38.5 with exactly the same saml2 settings, it works with INCEpTION 33.2, but not with INCEpTION 38.5. INCEpTION 34.4 seems to be the same as 38.5.
Can you provide access to an Azure IdP for testing/debugging this?
If you let me know your email address, we can send you the password for a test account that can access only the INCEpTION application.
If you send us the SAML metadata for your INCEpTION instance, we can set up your instance as a separate SAML application.
I could install test releases of INCEpTION that you provide in our INCEpTION environment.
Sent you a mail a few days ago. If you didn't see it, maybe check the spam.