Bitbucket Login error "The Response has an InResponseTo attribute: ONELOGIN while no InResponseTo was expected"

Summary

Bitbucket users may receive an error "You could not log in. There could be several reasons for this. Please try again." while trying to login via SSO.

The logs show error: "Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_A4e540dAA-3da4-1234-5678-8fc78c561234 while no InResponseTo was expected"

Environment

The solution has been validated in Bitbucket Data Center 8.16.2 and 8.19.3, but may be applicable to other versions. This affects Bitbucket Data Center running with:

• SSO Integration with Microsoft Azure/Entra

• Reverse proxy or WAF

Diagnosis

The following error will appear in the atlassian-bitbucket.log file:

Capture a HAR while reproducing the issue

Generate HAR file following the guide Generating HAR files and analyzing web requests. From analyzing the HAR, you will see session-data-xxxx-xxx-xxxx-xxxx cookie value is empty.

Cause

• The LDAP Active Directory used to authenticate SAML users is disabled or has any issues.

• Changes applied in the LDAP configuration recently that caused synchronization failure.

• The error exception "Received invalid SAML response: The Response has an InResponseTo attribute: ONELOGIN_######aBc##fgc while no InResponseTo was expected" is returned mostly when the Reverse proxy/WAF(Web Application Firewall) blocks some session data. The session-data-xxxx-xxx-xxxx-xxxx cookies were not being sent to the backend server by the reverse proxy/WAF.

Solution

If using reverse proxy/WAF, the solution is to inspect the traffic on the Reverse proxy & validate where the session cookie data is being filtered out. Ensure that session cookie data is forwarded from the reverse proxy to the backend servers.

For other causes, 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_users list before “Allow basic authentication on API calls” will be disabled, follow this KB: Creating an allowlist when basic authentication is disabled

• Initially, (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_setting database table first:

• Then use the below query to help you change the “Allow basic authentication on API calls” option:

• Now use the user as recovery_admin user, 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.