JIRA & Confluence Nordic Conference 9.10.2014 Jussi Haaja, Ambientia

1. Authentication and beyond,
Atlassian applications
JIRA and Confluence Nordic
Conference 2014
Jussi Haaja
Senior Systems Specialist
Twitter @jussihaaja

2. 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)

3. 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

4. The Basics
• The enabling technology
• Integrating with Active Directory
• Using Atlassian Crowd

5. 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.

6. 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

7. 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

8. 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

9. 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

10. 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

11. Single Sign-On
• The basic principles
• Using Atlassian Crowd
• Using operating system’s components
• Using authentication plugins
• Deciding on a SSO implementation strategy

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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.

18. 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.

19. A couple of real world examples
• Kerberos
• Active Directory Federation Services

20. 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: thesecomponents can reside within a single server
Confluence serverService user
Authenticated to Windows domain
as username
HTTP
Active Directory
Kerberos KDC
Web server
Apache httpd
mod_auth_kerb
Kerberos traffic
AJP (Apache JServ)
REMOTE_USER = username

21. Real world examples: Active Directory
Federation Services
Note: thesecomponents can reside within a single server
Confluence serverService user
Authenticated to Windows domain
as username
HTTP
Web server
Apache httpd
mod_shib
AJP (Apache JServ)
REMOTE_USER = username
Active Directory
Shibboleth service provider
shibd
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

22. Quick look on other applications
• Stash
• Bamboo
• FishEye

23. 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

24. 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

25. 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

26. 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

27. Final recap

28. 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

29. 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.

30. 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

31. Thank you!