Friendly security without compromise

Kantega Single Sign-on (SSO) gives you the easiest way to set up single sign-on for your Atlassian server products. An add-on for Confluence, Jira, Bitbucket, Bamboo and Crucible includes:

• SAML SSO

• Windows Intergrated Login (Kerberos)

• Cloud User Synchronization 

We proudly provide support for the two single sign-on protocols SAML and Kerberos. In addition, we have built connectors for synchronizing users and groups from popular cloud-based user directories. This enables you to manage your users' roles for your Atlassian server products in one centralized place. The connecor feature works elegantly together with SAML. Using our add-on makes it possible to combine Kerberos, SAML and regular username/password-based login, in a flexible way. Try our products

So which SSO solution do I choose, you say?

The two mechanisms we support, SAML and Kerberos, are what we consider the most prolific and secure.  At the same time, they have significant differences and are therefore applicable in different situations.  

Kerberos

Kerberos is capable of completely transparent SSO by having your browser deliver a Kerberos ticket to our add-on telling what user securely is logging in. Often, Kerberos is the preferred solution in a Windows based environment where login to the Windows machine can be used to automatically authenticate with the Atlassian server products through Windows Integrated Authentication (IWA). Kerberos requires that client machines have access to a Key Distribution Center (KDC), which in the Windows world generally means Active Directory. For security reasons, AD is generally not reachable outside the local network/corporate intranet, making Kerberos mainly applicable within a company.

SAML

SAML is flexible and widespread solution for single sign-on. It offers the ability to identify users in your Atlassian server products via practically any SAML 2.0 identity provider on the web. And there are probably thousands of these services. We have prepared wizard support and guides for the top 10-15 most common, but you should be able to use any SAML 2.0 compliant IdP.

SAML was designed for the WWW, and is quite different from Kerberos. In SAML, when users access the Atlassian server product without a valid session, they are redirected to an Identity Provider (IdP) login portal. This is typically a centralized web service for establishing users' identities and can range from the company's internal ADFS or KeyCloak server, to cloud providers like Google GSuite, Okta and Ping. Due to this redirection, and because most IdP authentication is username and password based, SAML is more "noticeable" for the user than Kerberos. However, SAML does not require a centralized KDC and so avoids the local network/intranet restriction that limits the use of Kerberos.

By also activating the connector feature in your SAML setup, we offer you to have a clean architecture by only leaving your users in your cloud based user directory. Whenever a user is created, removed or changes roles, this is synchronized through the connector to your favorite Atlassian server products. The connector creates a virtual user directory that your Atlassian server products see that contain all your users and groups from your cloud. Currenctly we have support for connectors to Azure AD, Google G-Suite and Okta.

In combination

Therefore, organizations often prefer to set up Kerberos for the most hassle-free login experience when the user is present at his desktop machine on the office. While SAML is set up in addition for enabling the user to log in when she is on the run outside the office or when accessing from cellphones or other non-Kerberos compatible devices.

Below you will find additional details about all the features of Kantega Single Sign-on.

Support

We take pride in offering quick, relevant and effective support. If you have a problem, please reach out to us. Do not hesitate to contact us in case you have questions. See also our Kantega Single Sign-on FAQ

We will guide you through