Two-step verification login for Data Center

Hi developer community,

We’ve just announced a two-step verification login for Data Center. Have a look at the corresponding changelog entry for more details.

UPDATE 23.04.2024:
We have just released EAP for two-step-verification. Please check this changelog entry for more details.

UPDATE 20.05.2024:

In the meantime, should you have any inquiries, post them in the comment section below this article.

1 Like

Hi,

Thank you for this heads-up. Have you got projections on how this will behave on instances using a third-party add-on for authentication? Our add-ons are reliant on the servlet filter chain and the host application login page behavior in order to extend it for the functionality we are adding to the login experience.

Will this be a configurable opt-in experience, or will it take over in a future release of Data Center platform version x?

Also, any more details about the EAP? Where will we get access to this?

Likewise impact on apps that support user “impersonation” by switching the logged in user at runtime (when requested by a system admin).

Shame there was no RFC for this.

For example, I as a vendor might want to force an additional 2FA check on security sensitive parts of my app. Coincidentally we were discussing implementing this minutes before this announcement.

5 Likes

@rlander do these “impersonation” solutions rely on using the login page?

We intend adding 2SV for some parts of the admin panel in the future version. We could possibly consider making this feature available also to marketplace partners.

Will this be a configurable opt-in experience, or will it take over in a future release of Data Center platform version x?

We aim to deliver it by next week. The announcement will be made through a new EAP changelog entry, along with a downloadable jar file.

This is the main goal of the POC EAP we are preparing. The POC only includes the basic mechanism and is not a final solution. We gather this feedback to guarantee that the ultimate solution does not disrupt the authentication-related plugins.

I’m wondering if this change has other changes to the fundamentals of auth in the platform.

Is this merely a new login page? Or has more changed behind the scenes.

We can just test with the jar when available.

It’s a new login page, however the change can affect plugins which depend on the current login page layout as well as plugins which intercept requests to the login page.

Dear developer community, the EAP for two-step verification is now available. We’ve updated the announcement.

1 Like

Cool. Is it compatible with pre-platform 7?

1 Like

Absolutely, the EAP does not require Platform 7 and should work with all Jira and Confluence versions compatible with the 4.3.x version line of Atlassian’s SSO plugin - that’d be Jira 9.13.x and Confluence 8.8.x. I have successfully tested the plugin against Jira 9.13.0 and Confluence 8.8.0. This is not an exhaustive version list as the plugin seemed to work with Jira 9.12.1 as well. I have also successfully tested it with Jira 10.0 EAP 02 but I would not be surprised if it didn’t work with future Platform 7 EAPs.

Hi @Patryk, will 2FA be able to be disabled? We run end-to-end tests for our DC apps and would like to not have to navigate 2FA in that scenario

Thanks!

We have tested it, and our app can still perform SSO with minor changes to our code using the first EAP. From what I see, this two-step verification only triggers after local username/password login and not interfering otherwise with filters or login events. This is ideal for us because we often enforce 2fa during SSO performed at the IDP side for our customers’ setup. In those cases a double 2fa makes no sense, so glad to see it doesn’t break SSO.

Please let us know if any functional changes are coming in a later version that we should be aware of.

1 Like

Hey Sam,

We plan to have a way to completely disable the feature in dire circumstances, but it should be used as a last resort. Could you tell me more about those tests - are they executed via AMPS or another integration test mechanism against short-lived instances that function only for the duration of the tests or are these tests executed on long-living instances, for example as means of certification? There may be better means of handling MFA for the tests that you’re running, so I’d like to understand your usecase better. You can also reach us via DM if you’d rather not share details of your tests with a wider audience.

Hi @Patryk,

We plan to have a way to completely disable the feature in dire circumstances, but it should be used as a last resort.

Can this please be made available by some publicly-published JVM parameter that can be configured at app startup?

I spin up multiple Confluence instances (as do many other vendors) inside a private CI environment to test cross-version compatibility. These are full production instances (not AMPS) designed to mimic a customer’s system as closely as possible, but they are not publicly accessible.

Scripts automatically log in with the ?os_username=admin&os_password=password query parameters (via the existing -Datlassian.allow.insecure.url.parameter.login=true) and it does what we need. Ideally, we could just add a new JVM parameter so that we do not have to work around the 2FA login page.

2 Likes

Hey Sam,

We plan to have a way to completely disable the feature in dire circumstances, but it should be used as a last resort. Could you tell me more about those tests - are they executed via AMPS or another integration test mechanism against short-lived instances that function only for the duration of the tests or are these tests executed on long-living instances, for example as means of certification? There may be better means of handling MFA for the tests that you’re running, so I’d like to understand your usecase better. You can also reach us via DM if you’d rather not share details of your tests with a wider audience.

We run tests on both long-lived and short-lived instances with the end-to-end testing framework Playwright.

Hey @scott.dudley ,

Absolutely - we will provide a JVM parameter configurable at app startup to restore legacy authentication behavior. This would allow you to use currently available means of authentication for your purposes. The parameter is intended to either facilitate testing or as a last resort in dire cases - ideally it wouldn’t be used on proper production instances.

1 Like