Tech Talk : Enabling Single Sign on (SSO) to Atlassian JIRA, Confluence and Jenkins application using Akamai Enterprise Application Access service

Single Sign On (SSO) functionality facilitates the users to login to one application through a reverse proxy and automatically signed in to other applications hosted behind the reverse proxy regardless of the platform, technology and domain. Users do not need to remember passwords for different applications and websites to login. With the help of single ID credentials, they can access multiple enterprise applications. With the assistance of single ID credentials, users can login to multiple applications and websites. Implementing SSO also results in reducing the password related help desk support call , this reduces the workload and increases the productivity.

There are different methods to implement single sign on (SSO) for various applications;

• Federation based SSO (for example: OKTA)
• Windows based Authentication (Kerberos or NTLM)
• Web-based or Header based SSO.

HTTP headers offer great flexibility for passing critical information to the enterprise applications including custom headers . Based on HTTP headers, you can make your enterprise applications Single Sign on (SSO) capable through a reverse proxy even if the applications cannot be SAMLized or integrated with Windows authentication mechanism (Kerberos/NTLM). Enterprise Web applications from vendors like Atlassian, Oracle, SAP or any home grown application can authenticate end-users based on the information http header presents in the form of custom attribute (for example, Client IP or remote user) . Applications like JIRA, Confluence, Jenkins or Oracle PeopleSoft either support these headers natively or using Java based plugins available as open source for authentication.

Akamai Enterprise Application Access service provides http header injection to any application it protects and make it Single Sign On (SSO) enabled. In addition, EAA sits in the data-path and in complete control of the end user session cookie, hackers cannot inject their own HTTP headers to spoof the system.  Using HTTP headers, EAA can provide secure remote access and single sign on (SSO) experience to enterprise applications with web front-end using either SAML IdPs (for example Okta) or on-prem Active directory/LDAP. 

Single Sign On (SSO) for Atlassian applications (JIRA and Confluence)

In this example, Atlassian JIRA and Confluence applications are running behind the firewall protected through Enterprise Application Access. Both applications uses Seraph plugin to receive custom HTTP headers from EAA and uses this information to authenticate the user into the application. For detailed steps and configuration, please follow the instructions mentioned in following knowledge base articles:

Enterprise Application Access KB article: SSO for Atlassian JIRA

Single Sign On (SSO) Authentication For Atlassian JIRA

Enterprise Application Access KB article: SSO for Atlassian Confluence

Single Sign On (SSO) Authentication For Atlassian Confluence

Single Sign On (SSO) for Jenkins

Jenkins application uses "reverse-proxy-auth-plugin" that lets you delegate the authentication to EAA, which protects Jenkins application. It also includes authorization, which is done via LDAP groups synchronized in EAA Cloud Edge.The plugin requires following header attributes for SSO;

• Header User Name: X-Forwarded-User
• Header Groups Name: X-Forwarded-Groups
• Header Groups Delimiter: ","

Enterprise Application Access KB article: SSO for Atlassian Jenkins

Single Sign On For Jenkins