Atlassian two-step verification login for Data Center
Links
Announcement https://developer.atlassian.com/server/jira/platform/changelog/#CHANGE-1570
EAP01: http://developer.atlassian.com/changelog/#CHANGE-1595
Atlassian Developer Community thread: https://community.developer.atlassian.com/t/two-step-verification-login-for-data-center/79009/12
Situation
Atlassian will introduce a new 2SV feature that is based on/ coupled with the Atlassian SSO plugin.
Atlassian calls it 2-step-verification, but based on the information provided it uses 2 factors with TOTP. Users can use an authenticator app and manage their tokens in their personal Jira profile.
An early EAP with a POC implementation is scheduled for April 18.
The public release is scheduled for Jira 10.1 and Confluence 9.1 in July/August.
The Atlassian SSO plugin will be transformed from a bundled plugin to a system plugin.
The new 2SV will be the default authentication flow, but it will be possible to disable this method by setting a system property on startup.
There will be a way to configure different authentication methods in the admin section, but it is not planned to support any integrations with 3rd party applications yet.
They won’t enable 2SV if Atlassian SSO is configured, as they assume that then 2FA is done by the IdP.
The existing Seraph authentication will not be touched. The new solution will be added on top of the existing authentication implementation.
Authentication with the REST API is not affected, except for a custom Jira REST endpoint the provides a new Jira session, as this would act as a security hole.
Supporting WebSudo is not yet included, but is planned for a later release.
A follow up meeting 2-3 weeks after we receive the POC is planned. Depends on Team 24…
What we need to find out
Does the fallback (activated by setting the system property) work exactly like before? If yes, this is the minimal solution that we can provide to customers, if we run into problems with this new feature.
Can we intercept the new auth flow by redirecting like usual, maybe by checking different URLs in the servlet filter? This would mean that SSO still works after upgrading to the new host version, with the exception of some features like custom SSO buttons in the login page. Those customers would still need to use the fallback.
Does the new flow interfere with the mixed mode where we provide access to both login mechanism (SSO and local login)?
Can we inject custom code into the new templates to fully provide the existing feature set?
Test with EAP01
Default redirection still works with the new login page.
?nosso fallback also works as expected.
Injecting IdP buttons into the new login does not work.
→ Upgrading to the new version should work without downtime, except for the instances that have the redirection disabled and use IdP buttons.
→ Customers can use the old and the new login form together with our plugin.