Enforce SSO and MFA

Owned by Jon Espen Ingvaldsen (Unlicensed)
Last updated: Jul 18, 2024 by Steinar Line
4 min read

These settings apply to SAML, OpenID Connect, and Windows Integrated Authentication (Kerberos) and are found under the “Common” menu.

Prevent traditional login

Kantega Single Sign-on does not prevent the usage of traditional username/password login by default. Any user can cancel SSO and log in manually, provided they are provisioned in a way that gives them passwords in the first place. This can sometimes be undesirable, for example, when users are provisioned through AD/LDAP where passwords are available - but the organization wishes to require the use of 2FA or SmartCard.

To prevent traditional username/password login, go into the Kantega SSO configuration page. Under Common > Prevent traditional login, you find a toggle box to prevent traditional login.

When preventing username and password login, Kantega SSO will block local password logins for users with a license group, while also trying to hide password fields from login forms.

If traditional login is prevented, you will no longer be able to log in to an administrator account using username and password. Even so, retaining an admin account and password in the Internal directory is highly recommended as a backup in case you need to restore SSO functionality.

If necessary, you may re-enable password login by deleting the following file on your Atlassian product server:

<atlassian_home_folder>/kerberos/disable_username_password_login.txt

It takes up to one minute for change to take effect if you disable it by removing the file and on other cluster nodes if applicable.

Note that only the standard login forms are prevented from username/password login, not the core password/directory system. Username and password login may still be usable through third-party plugins/applications if they run their own password validation.

Force login

Kantega Single Sign-on will, by default, only authenticate users where your Atlassian product would otherwise require them to log in with a username and password.

By activating Require login, users may be logged in also on pages that normally do not require this. The following pages will require login when the toggle is activated.

 

In addition you can specify additional Force login paths

You may also exclude certain of the build-in path prefixes from the above list. Exclusion paths will be evaluated as "starts with". so using * in the end is not neccesary.

Multi-factor authentication (MFA)

Enable multi-factor authentication requirement on your Identity provider (IdP) if you require all logins from the IDP to use MFA. This assures that MFA was used on the IdP side during login.

Enforce multi-factor authentication

  1. Select Identity Providers in the Ksso menu, and the identity Provider overview appears.




  2. Select the IDP which requires MFA, and the Identity Provider settings menu appears.

  3. Select Enforce multi-factor authentication and set the toggle “Require multi-factor authentication” ON.

 

 

You must enable multifactor authentication in the external Identity provider, as this will not automatically be triggered. Example: https://docs.microsoft.com/en-us/azure/active-directory/authentication/tutorial-enable-azure-mfa

 

Require multi-factor authentication is now supported on Identity providers with OIDC. Contact support if you need MFA enforcing on Identity providers with SAML.

 

Upcoming MFA built into Atlassian products

Atlassian announced April 2024 that they will build MFA/2FA into their products, see: Two-step verification login for Data Center. When this is getting closer to release ready from Atlassian, Kantega SSO will be prepared to work well in combination with the build-in MFA feature.

This is how a username/password login with the new MFA feature from Atlassian typically will work:

Step 1:

Step 2:

(On the very first login with username/password the MFA authenticator mechanism is set up typically using a QR code.)

At the moment the way Kantega SSO is planned to work is that whenever a user logs in with SSO (either via Kerberos or OIDC/SAML) this will buypass the built-in MFA functionality from Atlassian. This is because we consider the typical SSO use case to contain MFA along the way already.