SSO login fails with the "Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN while no InResponseTo was expected" error in Bitbucket Data Center
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
SSO login fails with the "Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_A4e540dAA-3da4-1234-5678-8fc78c561234 while no InResponseTo was expected" error in the Bitbucket Data Center.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
ERROR [http-nio-7990-exec-28] *1ABCDEFGx98x19293x96 10.xx.xx.xxx,10.xx.xx.xxx "POST /plugins/servlet/samlconsumer HTTP/1.1" c.a.p.a.s.w.f.ErrorHandlingFilter [UUID: b08d41b7] Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_A4e540dAA-3da4-1234-5678-8fc78c561234 while no InResponseTo was expected
com.atlassian.plugins.authentication.sso.web.saml.provider.InvalidSamlResponse: Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_A4e540dAA-3da4-1234-5678-8fc78c561234 while no InResponseTo was expected
at com.atlassian.plugins.authentication.sso.web.saml.provider.impl.OneloginJavaSamlProvider.lambda$extractSamlResponse$1(OneloginJavaSamlProvider.java:97)
at com.atlassian.plugin.util.ContextClassLoaderSwitchingUtil.runInContext(ContextClassLoaderSwitchingUtil.java:48)
at com.atlassian.plugins.authentication.sso.web.saml.provider.impl.OneloginJavaSamlProvider.extractSamlResponse(OneloginJavaSamlProvider.java:88)
at com.atlassian.plugins.authentication.sso.web.saml.SamlConsumerServlet.doPost(SamlConsumerServlet.java:98)
at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:24)
at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:24)
at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:24)
at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:24)
at com.atlassian.applinks.core.rest.context.ContextFilter.doFilter(ContextFilter.java:24)
at com.atlassian.analytics.client.filter.UniversalAnalyticsFilter.doFilter(UniversalAnalyticsFilter.java:75)
at com.atlassian.analytics.client.filter.AbstractHttpFilter.doFilter(AbstractHttpFilter.java:33)
at com.atlassian.plugins.authentication.sso.web.filter.ErrorHandlingFilter.doFilterInternal(ErrorHandlingFilter.java:79)Environment
Tested on Bitbucket Data Center 8.16.2
Applies to Bitbucket Server/Data Center 8.x
Diagnosis
Check if the LDAP Active Directory used to authenticate SAML users is disabled or having any issues.
Check if there is any change applied in the LDAP configuration recently that caused synchronization failure.
Cause
This issue generally occurs when LDAP configuration in Bitbucket gets changed (like LDAP user password) which internally causes LDAP authentication and synchronization failure in Bitbucket.
Solution
To resolve this issue, you need to first confirm whether the issue falls under one of the scenarios explained below:
Scenario 1:
When Basic Authentication (Username and Password) is disabled from the Login Page as well as for REST API (Allow basic authentication on API calls disabled):
Scenario 1 internally covers two different use cases:
Use Case 1
Bitbucket System Admin user present as an Internal Directory user in Bitbucket and it has been added to the allowed_users list before disabling Basic Authentication completely (from both the Login Option and API calls):
To know how to add a user in advance to the
allowed_userslist before “Allow basic authentication on API calls” will be disabled, follow this KB: Creating an allowlist when basic authentication is disabledInitially, (when the System Admin user “admin” is already added to allow list above), check the options under Authentication Methodspage on the Bitbucket Administration page:
While running an API call using an already added System Admin user of the internal directory: API result: (GET call). It represents that block-requests are set to true which needs to be set to false to let users login to the Bitbucket.
To resolve this scenario, run the PUT call to change the block request to false using the admin user:
Once done, follow the steps under the Scenario 2 heading below to resolve the issue.
Use Case 2
Bitbucket System Admin user, whether it is the LDAP user or not, added to allowed_users list before disabling Basic Authentication completely (from both Login Option and API calls).
In this case, you only have the option of using recovery_admin user (by enabling lockout_recovery process) but it is not allowed to change the “Allow basic authentication on API calls” if it is already disabled. In this case, you will neither be able to login to Bitbucket using username and password (Login form disabled error in Bitbucket UI when trying with recovery_admin user) nor will be able to run any REST API relevant to this issue like enabling auth_fallback or adding an allowed user list to Bitbucket.
For every API call, we will hit the following error:
To resolve this scenario, the only option is to access the database and update the following table after taking a complete backup of the database.
Query the
plugin_settingdatabase table first:
1
SELECT t.* FROM public.plugin_setting t WHERE namespace ILIKE 'com.atlassian.plugins.authentication.basicauth' OR key_name ILIKE 'com.atlassian.plugins.authentication.basicauth' OR key_value ILIKE 'com.atlassian.plugins.authentication.basicauth' LIMIT 10;Then use the below query to help you change the “Allow basic authentication on API calls” option:
1
UPDATE plugin_setting SET key_value = 'false' WHERE id = <id>; — id should be replaced based on the output we will receive from the very first query.Now use the user as
recovery_adminuser, enable the auth_fallback, and login to Bitbucket.
Once done, apply the required changes to initiate the LDAP synchronization or check if there is any issue with the LDAP configuration like a password. You can also verify if synchronization is working fine or not.
Scenario 2
When Basic Authentication is disabled from the Login Page but “Allow basic authentication on API calls” is enabled:
If the user has a system admin user in the internal directory: Just need to enable auth_fallback using the article and login with the system admin user.
If the user doesn’t have a system admin user in the internal directory: Need to enable lockout recovery first to get the recovery_admin user. Once done, enable auth_fallback with the help of recovery_admin user and login. Once it is done, apply the required changes and initiate the LDAP synchronization.
Was this helpful?