2FA is the standard solution to the password problem
Let me remind you something, in case you’ve been living underground for the last 15 years.
Passwords suck.
They suck so much that we have written an entire white paper about them.
But there’s some things you can do. If you want to make sure that passwords are used properly in your organization, you must follow the following process:
- Set up a single-sign on solution to minimize the number of passwords
- Protect your most important applications with 2-factor authentication. At resolution, for example, we use a one-time code shared with us by the password manager.
Let’s assume for the sake of this article that your SSO solution is connected to Atlassian applications.
How do you go about adding 2FA?
Option 1: Atlassian Access (for Cloud)
Adding 2FA to your Atlassian products when they’re on the cloud is a no-brainer: Atlassian Access provides that as one of its main features. You can read the full documentation here.
Option 2: Identity Provider & a SAML SSO plugin (for Server and Data Center)
If your Jira or Confluence instances are deployed on your own servers rather than on the cloud, Access will not be your solution. And there’s not a real alternative in terms of Atlassian products: Crowd doesn’t support 2FA.
However, most commercial Identity Providers do have quite sophisticated approaches to MFA, so you can easily define and enable your own authentication policy.
Okta’s assurance scale of authentication options
For example:
It’s important to remember that none of these IdPs will be able to communicate with your Jira or Confluence Server applications unless you use SAML SSO apps. Once you do that, your Jira or Confluence will be able to start exchanging information about your users via SAML… and your MFA policies will apply to them.
Option 3: 2FA plugin for Jira or Confluence Server
Another option is to add a plugin to your Atlassian stack that provides 2FA to a single Atlassian application, like a plugin for Jira or Confluence, either Server or Data Center. There are many options available in the Marketplace.
The most successful and better rated are:
- Secure Login (2FA) by Syracom, is available for Jira, Confluence and Bitbucket.
- Two-Factor Authentication/2FA by SecSign Technologies. Available for Jira, Confluence, Bitbucket, Bamboo, and Crowd.
- 2FA for U2F & TOTP, by Alpha Serve, is also available for Jira, Confluence, Bitbucket, Bamboo, and Crowd.
All of these Marketplace apps are available both in Server and Data Center, and have hundreds of customers and high ratings. We have even tested Syracom’s in the past and it was compatible with the usage of resolution’s SAML SSO apps for authentication.
These 2FA plugins for Jira and Confluence on-prem seem like a good option when your current IdP doesn’t provide any type of Multi-Factor Authentication, when you only have one Atlassian application that you want to protect with MFA, or when you simply don’t have an SSO setup yet.
Conclusion: Choosing the 2FA for Jira or Confluence Server with the best usability
Every option we’ve laid out is technically feasible and will give you a second-factor layer to secure your Atlassian tools.
But which one’s best from a usability perspective? Did you guess right? It’s clearly Option 2.
If you want the second factor in front of your users as part of their SSO login, the only option is to enable 2FA from the Identity Provider,
Remember the industry standard: create a single sign-on experience with 2FA so your users’ single password is protected.
Consider doing this even if you’re on the Atlassian cloud. As soon as you start multiplying the 2FA barriers after logging to specific applications, your users will be annoyed. And some of them may start taking shortcuts.
Would you like to learn more?
If you want to keep reading about the best practices for Enterprise User Management with Atlassian on-premises applications and how resolution apps can help you set them up, have a look at our white paper. No email form required.
