Authentication and beyond, Atlassian applications

JIRA and Confluence Nordic Conference 2014

Jussi Haaja

Senior Systems Specialist

Twitter @jussihaaja

Today’s topics

• Main focus on Confluence and JIRA

• Basic authentication options• Active Directory –integration• Using Atlassian Crowd

• Implementing Single Sign On• Atlassian Crowd• Utilizing operating system tools• Using application plugins• Choosing a SSO implementation strategy• Some real world examples

• Other applications (Stash, Bamboo, FishEye)

Me

• Senior Systems Specialist• In Ambientia from 2010 onwards• Part of Ambientia’s Data Centre

Services team

• Concept Owner of Ambientia Cloud• JIRA and Confluence SaaS service

• Lots of experience integrating different SSO systems to Atlassian applications

• Kerberos and NTLM• Active Directory Federation Services• Shibboleth (HAKA)

• Twitter @jussihaaja

The Basics

• The enabling technology• Integrating with Active Directory• Using Atlassian Crowd

The Basics: Technological platform

• Parts of Atlassian Crowd have been integrated into other Atlassian applications for a few years• Confluence from version 3.5 onwards• JIRA from version 4.1 onwards• The ”embedded Crowd” provides functionality to integrate external user

directories

• Confluence and JIRA also share the same internal authentication framework, Atlassian Seraph• Seraph can be extended (via custom plugins) to support different

authentication methods.

The Basics: Active Directory

• The basic Active Directory integration:• Configurable from the admin interface

• No editing of files necessary!

• Synchronizes users and groups from AD• AD groups can be used to manage access rights (eg. Confluence spaces,

JIRA projects)• Or you can use groups local to the application (but do not mix and match!)

• Authentication events happen against the AD server (no password data stored in the application)

• Note: Active Directory integration by itself does not provide SSO• Note: applies also to JIRA and Stash

Confluence server Active Directory server

LDAP or LDAPS

The Basics: Atlassian Crowd

• Conceptually similar to a plain AD integration• Users can reside either in:

• A Crowd Internal directory (in Crowd’s database)• In a external user directory Crowd acts as a proxy for (e.g. AD)

• Configurable from applications’ admin interface

• Of course, Crowd needs to be installed and configured separately..

Confluence server Atlassian Crowd

Crowd (HTTP)

Active Directory

LDAP or LDAPS

JIRA server

The Basics: Atlassian Crowd continued

• JIRA can be used as a low end Crowd substitute• User accounts for Confluence, Stash, Bamboo and FishEye can

be managed in JIRA without a separate Crowd-installation• This provides only centralized user account management, Single

Sign On is not possible

Confluence server Atlassian JIRA

Crowd (HTTP)

Active Directory

LDAP or LDAPS

Stash server

Should I use Crowd, then?

• Pros for using Crowd:• Drastically simplifies configuration in applications (complexity moved to

Crowd)• Especially when multiple external directories need to be configured per application

• Possibility to implement a Crowd based single-sign on (more on this later)• Crowd can be used to manage authentication for other Web applications

as well (via Crowd’s API and CrowdID, an OpenID server implementation)

• Cons for using Crowd:• Requires a Crowd installation, license and so on• Somewhat restricts types of SSO that can be done

Where Crowd really shines

Crowd SSO domain

Confluence server Atlassian Crowd

Crowd (HTTP)

Active Directory #2

LDAP or LDAPS

JIRA server Active Directory #1

Biz app server

- Easily create an SSO domain where logging in to a single application logs you into all Crowd-enabled applications at once

- Easily federate multiple external user directories to a single logon domain

Single Sign-On

• The basic principles• Using Atlassian Crowd• Using operating system’s components• Using authentication plugins• Deciding on a SSO implementation strategy

Single Sign-On basics

• Atlassian Seraph (the authentication framework used by Confluence and JIRA, remember?) allows extension of the authentication framework by implementing new authenticators which replace the out-of-the-box method of authenticating the user (user and password supplied by HTTP POST) by some other means

• Usually this means either:• Relying on an external authentication source to authenticate the user

• For example, Apache mod_auth –modules or similar

• Implementing the complete authentication chain within the authenticator plugin

Single Sign-On basics continues

• Most SSO implementations do not substitute a user directory integration

• This means that you need by some means provide/import/create the user accounts to the application

• Usually this is done by integrating the applications to either directly to Active Directory or via Atlassian Crowd• Or you can create the user accounts directly in the application• The SSO only performs the authentication• In most cases the user accounts have to be managed separately

Atlassian Crowd based SSO

• Crowd based SSO is a Web-based SSO implementation• It relies on a presence of a HTTP cookie called crowd.token_key

(although this can be changed)• Confluence and JIRA both come with an compatible authenticator

• As previously noted, Crowd based SSO can be fairly easily extended to other (non-Atlassian) applications as well

• The main downside is that Crowd based SSO cannot be integrated to workstation login

• This means that user needs to log in to one of the applications in the SSO domain using his/her username and password

Utilizing operating system’s components

• Utilizing operating system’s components for Single Sign On is usually accomplished by authenticating the user’s session on a Web frontend server (Apache httpd, IIS) or on the Web container level (Tomcat) and then passing the name of the authenticated user via HttpServletRequest object’s getRemoteUser method

• This method can be used with (for example):• Kerberos-based Single Sign On (using Apache httpd and mod_auth_kerb) that

is tied to Windows domain login• Shibboleth-based Single Sign On (using Apache httpd and mod_shib) with

either Active Directory Federation Services or other SAML 2.0 –compatible identity provider

• These approaches require use of a custom authenticator that can utilize the information passed from the frontend Web server• e.g. the Confluence HTTP authenticator

Using application specific plugins

• There are also application level plugins (custom authenticators) that perform the complete authentication chain by themselves

• Made by AppFusions and resolution among others

• These authenticators function independently, without help from operating system’s components

Deciding on a SSO strategy

• Most application level plugins (the ones that implement the complete authentication chain) are commercial and thus incur the cost of a license (up to thousands of dollars)

• Despite the costs, if you are not familiar (or do not have access to people with knowledge of) with your operating system’s authentication facilities or otherwise lack access to them, these plugins are a good option.

• Using application plugins also make the application more self-contained and easier to relocate.

Deciding on a SSO strategy continued

• On the flipside, you can get going without additional license costs when utilizing operating system’s facilities to implement the actual authentication event and just pass the results to the application server

• For instance, the Confluence HTTP Authenticator is a freely available authenticator without any licensing fees and can be used with a solution like this

• Utilizing operating sytem’s components also makes the code for the custom authenticator (if you cannot use a readily available one) a lot less complex since it only has to worry about being able to read a preauthenticated user name from the HTTP request object.

• Using your operating system’s components as parts of the application’s authentication chain make the application more dependent on the underlying operating system.• This may or may not be an issue. It all depends on your environment.

A couple of real world examples

• Kerberos• Active Directory Federation Services

Real world examples: Kerberos

Kerberos-based authentication is a ”workstation” SSO, which means that an user logged in to a Windows domain is automatically logged in to the SSO-enabled application (Confluence in this example)

For the Kerberos based SSO to work, a user account needs to be created in the Active Directory for the Confluence server with proper Service Principal Name mappings in place. The server running httpd also needs to be able to communicate with the Kerberos KDC (usually a domain controller in a Windows domain)

mod_auth_kerb also needs a working ”keytab file” to authenticate against Kerberos without supplying a username and password.

Note: these components can reside within a single server

Confluence serverService userAuthenticated to Windows domain

as username

HTTP

Active DirectoryKerberos KDC

Web serverApache httpd

mod_auth_kerb

Kerberos traffic

AJP (Apache JServ)REMOTE_USER = username

Real world examples: Active Directory Federation Services

Note: these components can reside within a single server

Confluence serverService userAuthenticated to Windows domain

as username

HTTP

Web serverApache httpd

mod_shib

AJP (Apache JServ)REMOTE_USER = username

Active Directory

Shibboleth service providershibd

ADFS Federation Server(with Active Directory backend)

• ADFS-based Single Sign-On utilizes the Active Directory Federation Services SAML 2.0 endpoints to authenticate users

• The Confluence server runs a Shibboleth service provider which is configured as a Relying Party to ADFS

• Authenticated user is presented to Confluence via REMOTE_USER header

• This is conceptually similar to the previous Kerberos example, although trickier to configure

• Usually used in environments where policies prohibit application server connections to domain controllers

Quick look on other applications

• Stash• Bamboo• FishEye

Other applications: Stash

• Unfortunately, Stash does not use Atlassian Seraph as it’s authentication framework• It uses Spring Security instead

• Crowd-based SSO is supported out of the box

• There is a experimental plugin by Michael Heemskerk (from Atlassian) available in BitBucket which provides a similar authentication mechanism as described in previous examples• ie. one that relies on presence of REMOTE_USER in the

HttpServletRequest

Other applications: Bamboo

• Bamboo uses Atlassian Seraph and as such it would be possible to implement an authenticator similar to ones that are available for Confluence and JIRA to implement SSO

• For whatever reason, even very recent versions of Bamboo do not have the embedded Crowd –functionality present in most of other Atlassian’s applications• Instead, Bamboo still relies on older, so called ”atlassian-user” way of

configuring the user directories• The name comes from the configuration file called ”atlassian-user.xml” in

which the configuration is stored

Other applications: FishEye

• FishEye uses a yet another authentication framework

• However, the authentication framework allows extensions and the default authenticator can be replaced by a custom one

• Of course, Crowd-based SSO is supported out-of-the-box

Other applications: summary

• Stash does have an experimental plug-in to utilize operating system’s components to perform authentication• It still needs more field testing to see if it is a viable solution or not in the

long run

• Bamboo’s authentication framework is built on Atlassian Seraph but unfortunately there are no freely available custom authenticators

• FishEye has its own authentication framework, for which freely available custom authenticators do not exist

Final recap

If you have a lot of Atlassian applications deployed

• Atlassian Crowd is supported by all Atlassian applications out-of-the-box• Although some configuration is required

• Crowd-based SSO can be extended to other than Atlassian applications by use of either• CrowdID (an OpenID server bundled with Crowd)• Apache httpd module mod_authnz_crowd• Custom code for your application

• Atlassian applications use multiple authentication frameworks, which would need separate plugins developed for each application to handle a single SSO solution

If you have an existing Single Sign On solution

• If you have an existing, organisation wide SSO-solution deployed, it might be worthwhile to bite the bullet and make Atlassian applications to utilize that solution

• If you can get away with it, my recommendation is to utilize operating system’s components to handle most of the authentication related tasks• Keep the applications’ custom authenticator dead simple• Many SSO-solutions offer e.g. Apache httpd modules that can be used to

handle the authentication

• I’ll admit there are cases where this is not feasible. Then you have to either develop the authenticators in-house or source them elsewhere.

If you are using only JIRA and/or Confluence and no existing SSO-solution exists

• As the amount of applications if fairly low, it probably makes sense to go for separate SSO implementations for both applications• e.g. Kerberos-based workstation SSO

• Again, keep the custom authenticators simple (or use publicly available ones) and utilize operating system’s components, if at all possible

• As usual, using Crowd is also a great option

Thank you!