SAML2

Federated authentication between two Identity Servers

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

In this post I shall be explaining how federated authentication can be used to redirect the authentication of a user to another Identity Server.

Download the Identity Server from here, if you have not done so already. The installation guide can be found here.

Checkout the repository of the travelocity SSO sample from the link below, follow these instructions to checkout a folder.

https://github.com/wso2/product-is/tree/master/modules/samples/sso

In this tutorial we will be using two Identity Server instances namely an internal IS running on port 9443, and an external IS running on port 9445. Check this post if you need more information on how to run multiple Identity Servers on different ports. The travelocity sample will be deployed on tomcat. The travelocity webapp will redirect the login to the external IS, which again will redirect the authentication to the internal IS. The stepwise scenario is as follows.

  1. User visits the travelocity website and clicks to login through SAML SSO then the user is redirected to the external IS.
  2. The external IS redirects the authentication to the internal IS.
  3. The internal IS login screen is displayed and the user enters the credentials.
  4. The user credentials are checked against the LDAP of the internal IS.
  5. If authenticated, the user is redirected back to the external IS.
  6. The external IS redirects the user back to travelocity website as a logged in user.

dfdf

Step 1: Travelocity.properties

Go to the directory you saved the sample in and open src/main/resources/travelocity.properties. Check if the the configuration is as below and change the port of the IdPURL to 9445.

SAML2.SPEntityId=travelocity.com

SAML2.AssertionConsumerURL=http://localhost:8080/travelocity.com/home.jsp

SAML2.IdPEntityId=localhost

SAML2.IdPURL=https://localhost:9445/samlsso

Step 2: External IS Configuration

The external IS should have a new Identity Provider configured to federate the users to the internal IS. It should also have a service provider configured to identify the webapp.

  1. Add a new Identity Provider in the internal IS. Give a name and expand Federated Authenticators then SAML2 Web SSO Configuration. Do the configuration as follows. 

123.png

Save the configuration.

  1. Add a new Service Provider and click on Configure under Inbound Authentication Configuration -> SAML2 Web SSO Configuration then do the configuration as follows.

45Expand the Local & Outbound Authentication Configuration, then click on the  Federated Authentication radio button then select the identity provider you configured from the drop down.

6

Save the configuration.

Step 3: Internal IS Configuration

A new service provider needs to be configured in the Internal IS with the external IS as the Assertion Consumer URL.

Add a new Service Provider and click on Configure under Inbound Authentication Configuration -> SAML2 Web SSO Configuration then do the configuration as follows.

89

Save the configuration.

Step 4: Testing the authentication

Now if you add a user to the internal IS, you should be able to log in with the user even though you have configured the service provider in the external IS.

The basic HTTP header flow is as follows.

http://localhost:8080/travelocity.com 1. User visits travelocity webpage
http://localhost:8080/travelocity.com/samlsso?SAML2.HTTPBinding=HTTP-Redirect 2. User clicks on the login with SAML hyperlink
https://localhost:9445/samlsso?SAMLRequest=**** 3. User is directed to the external IS
https://localhost:9443/samlsso?SAMLRequest=**** 4. User is directed to the login page of the internal IS from the external IS
https://localhost:9443/samlsso 5. User logs in
https://localhost:9445/commonauth 6. Logged in user is redirected back to external IS
https://localhost:9445/samlsso?sessionDataKey=**** 7. User is given a session data key and is considered a logged in user

Hope this helps, this would prove useful in scenarios where the service provider has to be registered in one IS while the LDAP has been configured to another IS. Do drop a comment if you come across any issues :)

IDP Initiated SSO vs SP Initiated SSO

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

When working with SSO with SAML, it is vital that one understands the difference between Identity Provider Initiated Single Sign On and Service Provider Initiated SSO. Before that, it’s important to understand who Identity Providers and Service Providers are and their differences.

Given below are the definitions from the OASIS Organization that created SAML.

“An Identity Provider is a kind of provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers within a federation, such as with web browser profiles”

“A Service Provider is a role donned by a system entity where the system entity provides services to principals or other system entities”

In the context of this discussion, an Identity Provider is basically an entity that provides authentication for it’s users, whereas the webapp using this service could be called as the Service Provider.  In the Travelocity Sample in my previous post, travelocity.com is the SP whereas the WSO2 Identity Server is the IDP.

Now the difference between IDP Initiated SSO and SP Initiated SSO is quite simple. In SP Initiated SSO, the Single Sign On process is initiated by the web application. The user first visits the webapp, then the user is redirected to the IDP along with an AuthnRequest generated at the SP. The Travelocity Sample in my previous post is a classic example of this scenario. When the user visits http://localhost:8080/travelocity.com, and when he clicks on the hyperlink to login with SAML, the webapp initiates the SSO process with an AuthnRequest. A sample of the AuthnRequest sent is given below.

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    AssertionConsumerServiceURL="http://localhost:8080/travelocity.com/home.jsp"
                    Destination="https://localhost:9443/samlsso"
                    ForceAuthn="false"
                    ID="0"
                    IsPassive="false"
                    IssueInstant="2016-01-18T12:36:02.365Z"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    Version="2.0"
                    >
    <samlp:Issuer xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">concurUSD</samlp:Issuer>
    <saml2p:NameIDPolicy xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                         AllowCreate="true"
                         Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
                         SPNameQualifier="Issuer"
                         />
    <saml2p:RequestedAuthnContext xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                                  Comparison="exact"
                                  >
        <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
    </saml2p:RequestedAuthnContext>
</samlp:AuthnRequest>

The AuthnRequest contains important information such as the Assertion Consumer URL, the issuer and the NameID Format which is required by the IDP to identify where to redirect the request. Having authenticated the user, the IDP responds with a SAML Response and the process is similar for both types after this.

On the other hand, when using IDP Initiated SSO, the user does not go through the webapp first, but rather is directed to the IDP. So the first thing the user sees is the authentication page of the IDP. This is done by using a query string along with the URL.

The sample URL with the query string used by the WSO2 IS running on localhost port 9443, is given below.

https://localhost:9443/samlsso?spEntityID=<sp-issuer&gt;

Here the <sp-issuer> is the Issuer value we define when creating a Service Provider in the WSO2 IS Management Console.

So in the same travelocity example, if I want to use IDP Initiated SSO, the first thing that needs to be done is to “Enable IdP Initiated SSO” in the Service Provider configuration in the WSO2 IS. This is done by selecting the Service Provider “travelocity.com” from the list of SPs, then Inbound Authentication Configuration -> SAML2 Web SSO Configuration. Then click on edit, then check the “Enable IdP Initiated SSO” check-box at the very bottom. The save the configuration.

Now instead of having to go through http://localhost:8080/travelocity.com, and having to click on the SAML 2 hyperlink, the user can directly go to the URL given below and he shall be directed to the WSO2 IS authentication page.

https://localhost:9443/samlsso?spEntityID=travelocity.com

Both these methods are equally used in real life and the choice of one over the other, depends heavily on the requirement of the user.

Hope you enjoyed the post, do drop a comment if I’ve missed anything :)

How the Travelocity Sample Works

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

If you’ve been following the Configuring Single Sign-On with SAML 2.0 on the WSO2 Identity Server Documentation, but can’t seem to figure out how SSO works on it, you’ve arrived at the right place. In this post I’ll be explaining my understanding of how the sample works. This might not be the most accurate description, so please feel free to drop a comment if I’ve mistaken something :)

You can checkout the sample from the SVN repository using the command given below.

svn co http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/is/5.0.0/modules/samples/sso/

The tree structure is given below,

12

Here the most important files for the purposes of this tutorial are, the java classes, the properties files, the web.xml and the home and index java servlet pages. The rest can be disregarded since they are not concerned with SSO.

To make this tutorial simple, we’ll be going through each of the components similar to the order in which they are referred in SAML2 based SSO. So once you have done the configuration based on the tutorial and the war file is deployed on tomcat, the first thing that happens when you visit http://localhost:8080/travelocity.com is that you will be directed to the index page.

Part 1: The index.jsp

Given below is the index page of the travelocity sample.

3

For this tutorial, we shall only be focused on “login with SAML from WSO2 Identity Server”. If you look at the source code of the index.jsp page, you will see that the hyperlink for the SAML Login is “samlsso”

4

So when you click on the “here” hyperlink, you will get redirected to http://localhost:8080/travelocity.com/samlsso but in reality you get directed to the authentication page of the WSO2 Identity Server which is given below.

x

This is where the next component comes into play. So let’s look at the SSOFilter.

Part 2: The SSOFilter

A filter is a way of performing filtered functionality on a java web application. Typically filters are used to perform some piece of functionality either before or after the primary functionality of the web application. The architecture of the filter is given below.

5

How the filter is triggered will be discussed in the web.xml (Part 3).

In this scenario, the SSO functionality has been implemented in the form of a filter using the WSO2 library org.wso2.carbon.identity.sso.agent. When the filter is triggered, the request is sent through the SSOFilter. Here a SAML Assertion is generated and the browser is redirected to the WSO2 IS authentication page and once a user is authenticated, the SAML Response is again sent through the filter. During this process the SAML response is validated using the public and private key pair found in the wso2carbon.jks file. Once the user is validated, the browser is redirected to the home.jsp which is the Assertion Consumer URL.

Part 3: The web.xml

The web.xml is the deployment descriptor file of a java web application and is used to determine how URLs map to servlets, which URLs require authentication, and other information. It can be found inside the WEB-INF directory in the webapp folder.

In the web.xml of travelocity, the SSOFilter is defined.

6

Here the filter class name is given to locate the jar file from the libraries. The jar file was added as a dependency in the pom.xml.

The filter mapping is used to initialize the filter. When a particular url is requested, if it contains any of the url-patterns as given in the filter mapping, the particular filter is initiated. In this scenario, when the url http://localhost:8080/travelocity.com/samlsso is requested, since it contains the /samlsso url pattern, the SSOFilter is initiated.

Now once the request is sent through the SSOFilter and the SAML Response is validated, the user is then redirected to the Assertion Consumer URL. In this case the consumer url is http://localhost:8080/travelocity.com/home.jsp. So next let’s look at the home.jsp.

Part 4: The home.jsp

7

In this example, the default dashboard of the webapp is implemented within the consumer url itself, but in practical situations, the consumer url merely redirects the user to the particular dashboard of the logged in user.

Given below is the source of the home.jsp.

8

The first few lines of code in the home.jsp are there to retrieve the attributes from the response. the claimedID and openIDAttributes are irrelevant because we are only focused on SAML in this tutorial. The subject is the username of the logged in user. The samlSSOAttributes and accessTokenResponseBean are also saved if needed to be used. At any point if any of the if statements become false, that means that the user is not validated, and redirects the browser back to the index.jsp.

The rest of the home.jsp is HTML and is fairly irrelevant except for the part where it displays the username of the logged in user from the subjectID.

g

That concludes the SAML process but to fully understand the working of SSO, it’s important to know how the properties file is defined and how it is loaded.

Part 5: The travelocity.properties

The file is found inside the resources folder and this file contains all the information about SAML based SSO for the travelocity.com webapp. The file is loaded to the SSOAgentConfigs by the SampleContextEventListener.java, which will be discussed in the next part.

The information in the properties file such as the issuerID, the Assertion Consumer URL are used by the SSOFilter to identify the Service Provider in the WSO2 Identity Server. This also says if the response and assertion are signed or not, which needs to be configured in the IS.

Other information such as the Keystore Password are used to retrieve the public and private keys from the keystore wso2carbon.jks, to validate the saml response received by the filter.

It is important to understand that the properties file nor the keystore are used by the web application but rather are used by the SSOFilter.

Part 6: The SampleContextEventListener.java

So how does the SSOFilter know where to find the properties file and the keystore. This is where the SampleContextEventListener.java is used. The SampleContextEventListener is initialized as a listener in the web.xml as follows.

t

When the webapp is deployed, the SampleContextEventListener loads the properties file and the keystore to the SSOAgentConfigs in the org.wso2.carbon.identity.sso.agent library. From here it is again retrieved whenever needed.

So that’s a brief explanation as to how the travelocity.com sample works, there’s much more to it, specially the functioanlity of the SSOFilter. Hope I covered everything correctly, do drop a comment if I’ve missed anything.

Integrating Salesforce with WSO2 Identity Server

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

This blog post focuses on enabling SAML 2 based Single Sign on for Salesforce, 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,

Step-by-Step Process

Step 1 : Configuring Salesforce
  1. Go to Salesforce and create an account.
  2. A domain name needs to be registered in order to redirect the login to WSO2 IS Authentication page. For this, login to salesforce with the newly created credentials and click on the Settings tab on the top right corner then select Setup Home.
  3. Expand the Company Settings tag from the left pane, then click on the My Domain link.
  4. Create a domain, for example samlssoexample.my.salesforce.com and deploy it. You will receive an email once the domain has been created.
  5. Expand the Identity tag from the left pane, then click on Single Sign-On Settings.
  6. Under Federated Single Sign-On Using SAML, click on the Edit button and tick the SAML Enabled Checkbox.
  7. Under SAML Single Sign-On Settings, click on the New Button, then fill out the details as below.
Name WSO2IS
API Name WSO2_IS
Issuer https://localhost:9443/samlsso [1]
Entity ID https://saml.salesforce.com
Identity Provider Certificate Download file from here [2]
Request Signing Certificate Default Certificate
Request Signature Method RSA-SHA1
Assertion Decryption Certificate Assertion not encrypted
SAML Identity Type Assertion contains User’s salesforce.com username
SAML Identity Location Identity is in the NameIdentifier element of the Subject statement
Service Provider Initiated HTTP POST
Identity Provider Login URL https://localhost:9443/samlsso
Identity Provider Logout URL https://localhost:9443/samlsso
User Provisioning Enabled Unchecked

[1] The issuer value should be equal to the entity value configured in the Identity Provider of the WSO2 Identity Server.

[2] The certificate file given corresponds to the default certificate used by the WSO2 IS. If a new certificate is used, an Idp with the certificate should be registered in the WSO2 IS.

The final configuration is given below.

config

8. Go back to the Domain Settings as in step 1.3

9. Under Authentication Configuration click on the Edit button then check the WSO2IS tick box and uncheck the Login Page checkbox.

10. Log out and close Salesforce.

Step 2 : Configuring WSO2 IS
  1. Start the WSO2 identity server and login to the server from https://localhost:9443/carbon/admin/login.jsp .
  2. Under Service Providers, click on Add and give a name and then Register.
  3. Then expand the Inbound Authentication Configuration under that expand SAML2 Web SSO Configuration then click on Configure.
  4. Give the configurations as below.
Issuer https://saml.salesforce.com
Assertion Consumer URL Check below
Use fully qualified username in the NameID Check
Enable Response Signing Check
Enable Response Signing Check
Enable Attribute Profile Check
Include Attributes in the Response Always Check
Enable IdP Initiated SSO Check

Leave the rest as default.

The Assertion Consumer URL can be found from the Single Sign-On Settings in Salesforce. Navigate to the SSO settings as shown in step 1.5 then click on WSO2IS. On the bottom of the page is an attribute called Salesforce Login URL. This URL is used as the Assertion Consumer URL.  

Then register the service provider.

The Final Configuration is given below.

IS

5. To check the authentication, a user with the same credentials used to create the Salesforce account is needed in the Identity Server. For this, Click on Configure on the left-most pane of the Identity Server Management Console, then click on Users and Roles from the left pane. Click on Users, then Add a new user, using the same credentials used for the Salesforce account.

Step 3 : Use SSO

Start the WSO2 Identity Server then goto the newly registered domain name url. The page should be redirected to the WSO2 Identity Server authentication page. If the configurations are correct,  when the credentials are given the page should be redirected to the dashboard of the logged in user.

Integrating Drupal with WSO2 Identity Server

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

This tutorial will focus on setting up SAML 2 based Single Sign On for Drupal using the WSO2 Identity Server as the Identity Provider. Here we will be using an Apache2 webserver with PHP5 support and MySQL support for deployment purposes. This tutorial uses Ubuntu 15.10 operating system for deployment and testing.

Prerequisites

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

Step-by-Step Process

Step 1: Configuring the prerequisites
  1. Install MySQL. Type the following command on the terminal with root access.

sudo apt-get install mysql-server mysql-client

You will be asked to set a root password for the MySQL root user. This password will be used in future for root@localhost.

  1. Install Apache2. Apache2 is sometimes installed by default in some ubuntu version. Either way run the following command to install or update it.

sudo apt-get install apache2

  1. Now go to http://localhost in your browser, if the installation was successful, you will be redirected to the apache2 default page.
  2. Install PHP5. Both PHP5 and Apache PHP module need to be installed. Run the following command to install them.

sudo apt-get install php5 libapache2-mod-php5

  1. Install MySQL support for PHP5.

sudo apt-get install php5-mysql

  1. Install the following php extensions using the following command. These are required for the SimpleSAMLphp Service Provider.

sudo apt-get install php5-cli php5-common php5-curl php-pear php5-mcrypt php5-json

  1. Install phpMyAdmin. phpMYAdmin is a web interface used to manage sql databases.

sudo apt-get install phpmyadmin

  1. Restart Apache using the following command then goto http://localhost/phpmyadmin to access phpmyadmin.

sudo service apache2 restart

IMPORTANT: For deployment purposes on a local server, an SSL Certificate has to be created for Apache2. This enables the web applications hosted on apache2 to be certified by SSL. Unless this is done the SimpleSAML module used, will throw an error. A separate doc is available on how to Create an SSL certificate for localhost….

Step 2: Setting up Drupal
  1. Download your preferred version of drupal from here.
  2. Extract the downloaded archive and copy the contents to /var/www/html/ using the following command. Here I have downloaded the version Drupal-6.37

sudo cp -r drupal-6.37 /var/www/html/

  1. Visit https://localhost/drupal-6.37/ on a web browser, if the deployment was successful, it should show the installation page of Drupal. Leave this for now and continue with the rest of the steps.
  2. Go to https://phpmyadmin/ and select the Databases tab then add a new database called drupaldb. Then click on the Check Privileges link next to the database then ensure that root user has Global Privileges by editing his privileges.
  3. Next we need to mark settings file of Drupal as writable for the initialization. Run the following commands to do this. You would need root access to do this, so run the command sudo su then enter the root password.

cd /var/www/html/drupal-6.37/sites/default

mkdir files

cp default.settings.php settings.php

chmod -R a+w .

  1. Add the following two lines to settings.php
ini_set('mbstring.http_input', 'pass');  
ini_set('mbstring.http_output', 'pass');  

 

  1. Go back to the Drupal installation page and use the following information to setup the databases.
Database Name drupaldb
Database username root
Database Password <your database root password>

NOTE: This password is the password that you set when installing MySQL and not your OS root password

  1. Once the configuration is complete, remove the write permissions from the ones changed in step 2.6 by running the following commands as a root user

cd /var/www/html/drupal-6.37/sites/default

chmod -R a-w .

  1. Finish the drupal installation, use the following information when asked.
Site name localhost
Username admin@wso2.com
E-mail address admin@wso2.com
Password admin
  1. Once the installation is complete, log out of drupal then log in again using the username admin@wso2.com and password admin
Step 3: Setting up SimpleSAMLPHP
  1. Run the following commands as a root user.

cd /var

mkdir simplesamlphp

cd simplesamlphp

wget http://simplesamlphp.googlecode.com/files/simplesamlphp-1.11.0.tar.gz

tar xvf simplesamlphp-1.11.0.tar.gz

mv simplesamlphp-1.11.0 simplesamlphp

cd simplesamlphp

cp -r metadata-templates/*.php metadata/

cp -r config-templates/*.php config

  1. Configure simpleSAMLphp web in Apache

cd /var/www/html

ln -s /var/simplesamlphp/simplesamlphp/www simplesaml

  1. Start apache using the following command

sudo service apache2 start

  1. If you are able to access the simpleSAMLphp web page using https://localhost/simplesaml, then the installation was successful.
  2. Change the SimpleSAML admin credentials.

cd /var/simplesamlphp/simplesamlphp  

vi config/config.php

Change the value of auth.adminpassword from 123 to admin.

  1. Go back to https://localhost/simplesaml and click on Login as administrator link then login using the admin credentials.
  2. Next we need to add a service provider to SimpleSAMLphp. Run the following commands to open the authsources.php file

cd /var/simplesamlphp/simplesamlphp  

vi config/authsources.php

  1. Comment out the default-sp configuration and add the following configuration to the file.
'wso2-sp' => array(
        'saml:SP',
        // The entity ID of this SP.
        // Can be NULL/unset, in which case an entity ID is generated based on the metadata URL.
        'entityID' => 'simplesaml',
 
        // The entity ID of the IdP this should SP should contact.
        // Can be NULL/unset, in which case the user will be shown a list of available IdPs.
        'idp' => 'https://localhost:9443/samlsso',
 
        // The URL to the discovery service.
        // Can be NULL/unset, in which case a builtin discovery service will be used.
        'discoURL' => NULL
 
),
  1. We have to change the identity provider metadata in SimpleSAML. Open the file using the following command.

cd /var/simplesamlphp/simplesamlphp  

vi metadata/saml20-idp-remote.php

  1. Remove the existing idp from the file and add the following details.

 

$metadata['https://localhost:9443/samlsso'] = array(
   'name' => array(
     'en' => 'WSO2 IS',
     'no' => 'WSO2 IS',
   ),
   'description'        => 'Login with WSO2 IS SAML2 IdP.',
 
   'SingleSignOnService'  => 'https://localhost:9443/samlsso',
   'SingleLogoutService'  => 'https://localhost:9443/samlsso',
   'certFingerprint'    => '6bf8e136eb36d4a56ea05c7ae4b9a45b63bf975d'
);

NOTE: The certFingerprint used here is the thumbprint of the default certificate used by WSO2 IS. The SAML response is signed with this certificate.

More information on this step can be obtained from here.  

Step 4: Setting up the WSO2 IS
  1. Start the WSO2 Identity Server and add a service provider. Give a name and check the Saas Application checkbox.
  2. Select Inbound Authentication Configuration, then SAML2 WEB SSO Configuration. Then click on configure and provide the following details.
Issuer simplesaml
Assertion Consumer URL https://localhost/simplesaml/module.php/saml/sp/saml2-acs.php/wso2-sp
Enable Assertion Signing True
Enable Single Logout True
Logout URL https://localhost/simplesamlphp/www/module.php/saml/sp/saml2-logout.php/wso2-sp
Enable Idp Initiates SSO True

Keep the rest as default values.

12

  1. Under Claim Configurations, select Define Custom Claim Dialect then add an Identity Provider Claim URI with the following information.
Service Provider Claim mail
Local Claim http://wso2.org/claims/emailaddress
Requested Claim True

The final configuration should look like this.

3.png4.png

  1. Now Go to https://localhost/simplesaml and click the Authentication tab and click on Test configured authentication sources. Pick wso2-sp and you will be redirected to the WSO2 IS Authentication Page, which means that the configuration was successful.
Step 5: Connecting Drupal with SimpleSAMLphp

1.Download the relevent simpleSAMLphp Authentication module from here.

  1. Create the following directory path and extract the downloaded archive into it.

cd /var/www/html/drupal-6.37/sites/all/modules

mkdir contrib

  1. Go to https://localhost/drupal-6.37/ and login to Drupal with admin credentials then nativate to Administer -> Site Building -> Modules. Then enable the SimpleSAMLphp Authentication which will be found under the other category.
  1. Click on the Administration by module link then under simpleSAMLphp authentication click on simpleSAMLphp authentication module settings

Select “Activate authentication via SimpleSAMLphp”.

Installation directory (default: /var/simplesamlphp) /var/simplesamlphp/simplesamlphp
Autenticaton source for this SP (default: default-sp) wso2-sp
Which attribute from simpleSAMLphp should be used as user’s name mail
Which attribute from simpleSAMLphp should be used as unique identifier for the user mail
Which attribute from simpleSAMLphp should be used as user mail address mail

The final configuration should look as below.

d1.pngd2.pngThen Save configuration.

  1. Go to phpmyadmin and create a database named, “SimpleSAMLphpDB” with username/password as root/<your password>.

6. Add the following lines to /var/simplesamlphp/simplesamlphp/config/config.php

'store.type' => 'sql',
'store.sql.dsn' => 'mysql:host=localhost;dbname=SimpleSAMLphpDB',
'store.sql.username' => 'root',
'store.sql.password' => 'root',
'store.sql.prefix' => '',
  1. Add the following entry to the /var/www/html/drupal-6.37/sites/default/settings.php 
$databases['SimpleSAMLphpDB']['default'] = array(
  'driver' => 'mysql',
  'database' => 'SimpleSAMLphpDB',
  'username' => 'root',
  'password' => 'root',
  'host' => 'localhost',
  'prefix' => '',
);
  1. Restart the apache server.
Step 6: Use SSO

Go to  https://localhost/drupal-6.37 then click on the Federated Log In link then you will be redirected to the WSO2 IS authentication page. You can login using WSO2 credentials and you will be redirected back to the Drupal Dashboard.

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.