Failed authentication or authentication loops

Applies to

Any OSLC application

Problem

User authenticates to the remote application, but the authentication does not appear to be working.

While OSLC Connect applications and ELM will enter a login loop, Polarion will display the following:

Cause

There can be various causes to this. To get a proper root cause, please review the following possible causes:

A popup to authenticate to your OSLC Connect application is closed or blocked

The authentication popup can be blocked by your browser.

How to determine if Firefox is blocking cookies

In Firefox’s settings, go to Privacy & Security > Permisions. There, you will see

You will either need to disable this, or add an exception for each of your OSLC applications.

How to determine if Chrome is blocking cookies

In Chrome’s settings, go to Privacy & Security > Site Settings > Pop-ups and redirects. There, you will see

You will either need to allow Sites to send pop-ups and use redirects by adding each of your OSLC applications to the exceptions list, or enable this for all sites.

If the browser popup blocker was enabled and you disabled it, or if there was a plugin acting as a popup-blocker and you disabled it, please try the failing interaction again.

There are blocked cookies in Chrome

Cookies are what is used by a given application to store its authentication. If the cookie is blocked, it cannot be used when navigating an OSLC application to interact with another OSLC application.

How can I review Chrome's blocked cookies

Click on the lock to open the security dropdown menu
Click on Cookies
In the Cookies in use window, click on the Blocked tab

If you see blocked cookies when navigating there just after you experienced the authentication problem, you will need to select the cookies, then click Allow.

Unfortunately, as of now, this procedure has to be performed by all impacted users.

Applications live on different domains

As mentioned in the above section, cookies are what is used by a given application to store its authentication. When that authentication needs to be shared by another site, as is needed between an OSLC client and an OSLC server in the OSLC interactions, and if those applications live on different domains, browsers will consider this is a 3rd-party attempting to use a cookie which is not his, and may prevent such usage as a security measure. This will default to a failure in Chrome, and may also break in Firefox if the corresponding security feature has been enabled.

How to check if my applications are using the same domain?

A simple URL is made as follows:

_{([] means optional, and * means it can be there from 0 to n times)}

<scheme>://<server>[.<sub-domain>*][.<domain>][:<port>][<path>]

If we try to map sample URLs, we would break the domain out as follows:

https://server.example.com/jira => example.com
https://server.in.a.far.away.sub.domain.example.com:9443/ => example.com
https://server.example/confluence => example
https://server/jira => no domain, considered as being de facto different domains

If no, you may want to review the load balancer configuration, if any. Some OSLC Connect applications are deployed on Atlassian on-premise applications, where the Traffic Distribution feature may have been enabled. Unfortunately, that feature is currently not compatible with our OSLC Connect application. If the problem persists after you checked the load balancer, please reach out to us by creating a support request.

If yes, proceed with the below.

If your OSLC Connect application was already “SameSite=None enabled” at the application server level, that configuration should be removed. Since the release of the Security feature in our OSLC Connect products, we recommend customers to disable any former configuration and rely on that Security feature, which provides better security for OSLC Connect products. If you don’t know about that, it is likely not the case.

Note that depending on the version of Firefox, this either means that Firefox is not requiring the “samesite=none” property on cookies, or that Chrome is blocking cookies for some reasons.

You can use your browser to confirm the cause, as suggested below.

Confirming Firefox's configuration

You can confirm Firefox’s configuration by opening a new tab and entering about:config.

There you will be able to search for every configuration parameter of Firefox. Search for laxByDefault. The first result should be network.cookie.sameSite.laxByDefault.

If the value is true, Chrome and Firefox should behave the same. If the value is false, it wouldn’t be surprising for Chrome and Firefox to behave differently.

Note: for a secured and consistent experience across browsers, we recommend users set this value to true.

Confirming Chrome's configuration

A user can do a quick determination of the cause by validating the following (using Chrome before version 91, where those settings have unfortunately been removed).

Use the Chrome browser after updating flags as outlined below
Navigate to chrome://flags and disable “SameSite by default cookies” and “Cookies without SameSite must be secure”. Example in the screenshot below.

Relaunch Chrome and attempt the OSLC behaviors of authentication, linking, and previews.

If the behavior works, you will need to see the next section on how to fix it. As a workaround, all users can leverage this capability of Chrome while the resolution is made more permanently.

If enabling the above features in an unaffected browser triggers the problem, or vice versa if disabling it in an affected browser resolves the issue, you will find more details about the cause as well as a resolution in Embedded Content or Authentication Isn't Working between OSLC Applications.

If there was no blocked cookies, and you happen to experience the problem, please reach out to us by creating a support request.