Integrating Atlassian JIRA with WSO2 Identity Server

pulasthiharasgama SAML 2, SSO, WSO2 Identity Server , , , , , , ,

This post is on how you can configure SAML 2 based SSO for Atlassian JIRA, using the WSO2 Identity Server as the Identity Provider. Note that this configuration is very similar to the configuration for Confluence, which can be found here, since both Confluence and JIRA are products of Atlassian.

Prerequisites

WSO2 Identity Server

The WSO2 Identity Server download link and the installation guide are given below,

Atlassian JIRA

The JIRA download link and installation guide and given below. This tutorials has been tested with the JIRA Version 6.4, slight modifications might be required for other versions.

LastPass JIRA SAML Plugin

The plugin is required to configure SAML 2.0 SSO for JIRA. The download link is given below and the installation guide can be found in the file named INSTALL in the main folder.

IMPORTANT: Step 1 should be completed before the plugin installation as the plugin installation disables the default user login process which makes it difficult to do configurations inside the JIRA dashboard.

Step-by-Step Process

Step 1: Configuring JIRA LDAP

This step requires a working knowledge on LDAP, follow this link if you are unfamiliar with the concept.

JIRA by default uses an internal LDAP to keep track of the users and permissions. In order to integrate the WSO2 IS with JIRA, both LDAPs should point to the same LDAP instance. Here we are configuring the JIRA LDAP instance to point to the WSO2 IS LDAP.

  1. Once inside the JIRA dashboard, click on the cog icon, on the top pane and select User Management.
  2. Click on the User Directories link on the left-hand pane.
  3. Select Add Directory then select LDAP from the drop down menu.
  4. The configuration is given below

1 2 3 4 5

Test the configuration while having the WSO2 IS running. Then save.

NOTES

  • This configuration was done after configuring the WSO2 IS to accept email authentication. The configuration would slightly change unless this is done. See here for more information.
  • WSO2 IS by default uses port 10389 for the LDAP, this can be changed by changing the  <IS_HOME>/repository/conf/user-mgt.xml file. 
Step 2: Configuring JIRA
  1. Stop JIRA and install the LastPass plugin.
  2. Change the name of idp-metadata.xml.sample to idp-metadata.xml and sp-metadata.xml.sample to sp-metadata.xml. These two files are found in your <JIRA_HOME> directory.
  3. Change the <JIRA_HOME>/idp-metadata.xml as follows
  • Change the entityID value to the issuer name you will be configuring the Service Provider in your IdP with. For this tutorial we will be setting this as “LastPass-JIRA”.
  • Replace the <md:SingleSignOnService….> tag with
<md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
Location="https://localhost:9443/samlsso"/>
  • Add this after the replacement
<md:SingleSignOnService
Binding="urn:oasis:names:tc:SAML:2.0:
bindings:HTTP-POST" 
Location="https://localhost:9443/samlsso"/>
  • Replace the <md:SingleLogoutService….> tag with
<md:SingleLogoutService 
Binding="urn:oasis:names:tc:SAML:2.0:
bindings:HTTP-Redirect" 
Location="https://localhost:9443/samlsso" 
ResponseLocation="https://localhost:9443/samlsso"/>
  • Replace the “cert-goes-here” between the <ds:X509Certificate> tags with your certificate. WSO2 IS default certificate can be found here.

(Use without the –BEGIN– and –ENG– tags)

NOTE: The edited idp-metadata.xml file should look like this.

  4. Change the <JIRA_HOME>/sp-metadata.xml as follows

  • Change the entityID to the issuer value as above, in this case to “LastPass-JIRA”.
  • Replace “http://jira.example.com ” with your JIRA URL, in this case that is “http://localhost:PORT ” .  Replace PORT with the port JIRA is running on, by default it is 8080. I have configured JIRA with port 8070.

NOTE: The edited sp-metadata.xml file should look like this.

5. Add the following line after initializing “originalURL” in <JIRA_HOME>/atlassian-jira/saml_acs.jsp

originalUrl = “/secure/Dashboard.jspa“;

Step 3: Configuring WSO2 IS
  1. Select Add under the Service Provider section on the left pane.
  2. Give a name and register the Service Provider.
  3. Click on “Inbound Authentication Configuration” under that click on “SAML Web SSO Configuration”. Then click on “Configure”
  4. Give the following values
    • Issuer = LastPass-JIRA (The value has to equal the value we gave for issuer in Step 2)
    • Assertion Consumer URL = http://localhost:8070/saml_acs.jsp
    • Check “Use fully qualified username in the NameID”
    • Check “Enable Response Signing“
    • Check “Enable Assertion Signing”
    • Check “Enable Single Logout“
  5. Click Register then update.
Step 4: Patch the WSO2 IS

The Identity Server needs to be patched to include an attribute of the authentication statement. This is an optional attribute according to the SAML Specification, so the IS does not set it. The plugin searches for this attribute and throws an error if it is unavailable.

Add the following line in the buildSAMLAssertion() method after initializing the authStmt in this class,

authStmt.setSessionNotOnOrAfter(notOnOrAfter);

Step 5: Run the Server

Now we are all set, run JIRA and the WSO2 IS. The JIRA default url should redirect you to the WSO2 IS authentication page. When you enter the credentials, you will be redirected to the JIRA Dashboard of the logged in user.

Troubleshooting

 

Hope this helps, do drop a comment if there’s any thing you need clarified. Have fun!

Integrating Atlassian Confluence with WSO2 Identity Server

pulasthiharasgama SAML 2, SSO, WSO2 Identity Server , , , , , , ,

The next series of posts will focus on how SAML 2.0 based SSO can be configured for specific third party applications using the WSO2 Identity Server as the IdP. Once all the configurations are complete, the user will have the ability to use any of these applications, having been authenticated once by the WSO2 Identity Server.

This post is on how SAML 2 based Single Sign On can  be configured for Atlassian Confluence using the WSO2 Identity Server as the Identity Provider.

Prerequisites

WSO2 Identity Server

The WSO2 Identity Server download link and the installation guide are given below,

Atlassian Confluence

The Confluence download link and installation guide and given below. This tutorials has been tested with the Confluence Version 5.7.1, slight modifications might be required for other versions.

LastPass Confluence SAML Plugin

The plugin is required to configure SAML 2.0 SSO for confluence. The download link is given below and the installation guide can be found in the file named INSTALL in the main folder.

IMPORTANT: Step 1 should be completed before the plugin installation as the plugin installation disables the default user login process which makes it difficult to do configurations inside the confluence dashboard.

Step-by-Step Process

Step 1: Configuring Confluence LDAP

This step requires a working knowledge on LDAP, follow this link if you are unfamiliar with the concept.

Confluence by default uses an internal LDAP to keep track of the users and permissions. In order to integrate the WSO2 IS with Confluence, both LDAPs should point to the same LDAP instance. Here we are configuring the confluence LDAP instance to point to the WSO2 IS LDAP.

  1. Once inside the confluence dashboard, click on the cog icon, on the top pane and select User Management.
  2. Click on the User Directories link on the left-hand pane.
  3. Select Add Directory then select LDAP from the drop down menu.
  4. The configuration is given below

1

2 3 45

 

Test the configuration while having the WSO2 IS running. Then save.

NOTES

  • This configuration was done after configuring the WSO2 IS to accept email authentication. The configuration would slightly change unless this is done. See here for more information.
  • WSO2 IS by default uses port 10389 for the LDAP, this can be changed by changing the  <IS_HOME>/repository/conf/user-mgt.xml file. 
Step 2: Configuring Confluence
  1. Stop Confluence and install the LastPass plugin.
  2. Change the name of idp-metadata.xml.sample to idp-metadata.xml and sp-metadata.xml.sample to sp-metadata.xml. These two files are found in your <CONFLUENCE_HOME> directory.
  3. Change the <CONFLUENCE_HOME>/idp-metadata.xml as follows
  • Change the entityID value to the issuer name you will be configuring the Service Provider in your IdP with. For this tutorial we will be setting this as “LastPass-Confluence”.
  • Replace the <md:SingleSignOnService….> tag with
<md:SingleSignOnService Binding=“urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect” Location=“https://localhost:9443/samlsso>
  • Replace the <md:SingleLogoutService….> tag with
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://localhost:9443/samlsso"/>
  • Replace the “cert-goes-here” between the <ds:X509Certificate> tags with your certificate. WSO2 IS default certificate can be found here.

(Use without the –BEGIN– and –ENG– tags)

NOTE: The edited idp-metadata.xml file should look like this.

    4. Change the <CONFLUENCE_HOME>/sp-metadata.xml as follows

  • Change the entityID to the issuer value as above, in this case to “LastPass-Confluence”.
  • Replace “http://confluence.example.com ” with your confluence URL, in this case that is “http://localhost:PORT ” .  Replace PORT with the port confluence is running on, by default it is 8090.

NOTE: The edited sp-metadata.xml file should look like this.

Step 3: Configuring WSO2 IS
  1. Select Add under the Service Provider section on the left pane.
  2. Give a name and register the Service Provider.
  3. Click on “Inbound Authentication Configuration” under that click on “SAML Web SSO Configuration”. Then click on “Configure”
  4. Give the following values
    • Issuer = LastPass-Confluence (The value has to equal the value we gave for issuer in Step 2)
    • Assertion Consumer URL = http://localhost:8090/saml_acs.jsp
    • Check “Use fully qualified username in the NameID”
    • Check “Enable Response Signing“
    • Check “Enable Assertion Signing”
    • Check “Enable Single Logout“
  5. Click Register then update.
Step 4: Patch the WSO2 IS

The Identity Server needs to be patched to include an attribute of the authentication statement. This is an optional attribute according to the SAML Specification, so the IS does not set it. The plugin searches for this attribute and throws an error if it is unavailable.

Add the following line in the buildSAMLAssertion() method after initializing the authStmt in this class,

authStmt.setSessionNotOnOrAfter(notOnOrAfter);

Step 5: Run the Server

Now we are all set, run Confluence and the WSO2 IS. The Confluence default url should redirect you to the WSO2 IS authentication page. When you enter the credentials, you will be redirected to the Confluence Dashboard of the logged in user.

Do drop a comment if you have any problems. Have fun! :)

SAML 2.0 based Single Sign On

pulasthiharasgama SAML 2, SSO, Uncategorized, WSO2 Identity Server , ,

Hi there!

If you are looking for documentation and information on implementing a SAML 2.0 based Single Sign On (SSO) system, and can’t seem to find much online references, you’ve arrived at the correct place. In the next few posts we’ll be discussing everything you need to know about implementing a SAML 2.0 based SSO systen.

Before we get started, we need to first understand what SSO and SAML are, and how they work

Single Sign On

Introduction

Single Sign On (SSO) is an access control property for multiple independent software systems.  Is is a user authentication process that permits a user to enter a single username and password and be given access to an array of multiple applications. The SSO system authenticates the particular user for all the applications and services that he has been given the right to access, which eliminates the need for further authentication when accessing these applications or services.

“Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable but difficult to implement”

-The Open Group-

SSO is typically “difficult to implement” due to different applications and services, supporting different authentication mechanisms. Thus the SSO mechanism implanted, should have the ability to translate the credentials used for initial authentication, to be used to access the other applications and services.

Conversely, Single Single Sign Off or Single Log-out is the process where a single logging out, terminates the access to multiple applications and services.

Configurations
Kerberos

Kerberos is an authentication mechanism which uses tickets to access different applications and services. The initial  authentication at the Authentication Server (AS), grants the user an encrypted Ticket Granting Ticket (TGT). When the client needs to access a particular service, the clients sends the TGT to the Ticket Granting Service (TGS) which verifies the validity of the ticket and issues a session key to the client to access the requested service.

Smart Cards

Smart cards are a hardware token. At initial authentication the user credentials are stored in the card which negates the need for the user to be authenticated every time the user access an application or a service. Provided that the user holds the smart card, the user is given access to these services.

Security Assertion Markup Language (SAML)

SAML is an XML standard. It is the most reliable and easy-to-implement SSO configuration, making it the most commonly used. It is mostly designed for business to business and business to consumer transactions. We’ll be talking more about SAML in the next post.

Benefits

The most common benefit is that SSO reduces the need for a user to remember different username-password combinations, thus improving the user experience. This in-turn reduces the possibility of errors and thereby increases productivity.

Drawbacks

The main drawback lies with the possibility of the username and password falling into the wrong hands. Unlike in a system that is not implemented with SSO, the damaged caused could be catastrophic. Thus the need for increased security and protection in an SSO implemented system is identified.

Security Assertion Markup Language (SAML)

SAML is an XML based protocol that is used in exchanging authentication and authorization data between domains with the use of tokens. SAML was produced by the OASIS Security Services Technical Committee in 2001. The latest version of SAML is SAML 2.0 which was accepted as an OASIS standard in 2005. SAML 2.0 is the key configuration used in SSO thus the focus of this discussion will be on SAML 2.0.

The working of SAML 2.0 SSO is given below.

0253642001447922228_saml_0

 

Once the process is complete, the Service Provider grants the user access to the service, based on the permissions defined in the service providers user database.

Where there are multiple service providers, SSO enables the client to use the same SAML token granted from the IdP, to access all the services. Thus the user need only be authenticated once by the IdP and thereafter given access to all the service providers.