Configuring Single Sign-On with SAML 2.0

Single-sign-on is one of the key features of the WSO2 Identity Server that enables users to access multiple applications using the same set of credentials. Additionally, the user can access all these applications without having to log into each and every one of them individually. So, if users log into application A, for example, they would automatically have access to application B as well for the duration of that session without having to re-enter their credentials.

The profiles specification for Security Assertion Markup Language 2.0 (SAML 2.0) defines single sign-on based on a web browser. This topic provides instructions on how to use the sample available in the WSO2 Identity Server to demonstrate how to configure SSO using SAML 2.0 with a sample service provider.

See the following topics for instructions on how to configure the sample with the WSO2 Identity Server.

Configuring the SSO web application

 To start off, you must obtain and configure the single sign-on sample. The following steps provide instructions on how to do this.

1. Use SVN to check out the source from the repository location that contains the single sign-on sample.

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

2. Remove the parent entry in the pom.xml file that comes along with the sample. The contents of the pom.xml file will look similar to the following.

   <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
   	<groupId>org.wso2.identity</groupId>
   	<version>5.0.0</version>	
   	<modelVersion>4.0.0</modelVersion>
   	<artifactId>wso2is-identity-samples-sso</artifactId>
   	<packaging>pom</packaging>
   	<name>Identity Server : SSO Samples</name>
   	<modules>
   		<module>SSOAgentSample</module>
   	</modules>
   </project>

   Alternatively, you can simply replace the existing pom.xml file with the sample pom.xml file.

3. In your command line, navigate to <SAMPLE_HOME>/sso/ in the folder you checked out and build the sample using the following command. You must have Apache Maven installed to do this (see Installation Prerequisites for the appropriate version to use).

   mvn clean install

4. After successfully building the sample, a .war file named travelocity.com can be found inside the <HOME>/sso/SSOAgentSample/target folder. Deploy this sample web app on a web container. To do this, use the Apache Tomcat server.

   Since this sample is written based on Servlet 3.0 it needs to be deployed on Tomcat 7.x.

   Use the following steps to deploy the web app in the web container:

   1. Stop the Apache Tomcat server if it is already running.
   2. Copy the travelocity.war file to the <TOMCAT_HOME>/webapps folder.
   3. Start the Apache Tomcat server.

Now the web application is successfully deployed on a web container. 

Configuring the service provider

The next step is to configure travelocity.com as the service provider. The following steps instruct you on how to do this.

1. Start the Identity Server and access the management console using https://localhost:9443/carbon/
2. Log in to the Identity Server using default administrator credentials (the username and password are both "admin").
3. In the management console found on the left of your screen, navigate to the Main menu and click Add under Service Provider. 
4. Expand the Inbound Authentication Configuration section and then expand SAML2 Web SSO Configuration. 
5. Click Configure. The following form appears. 
   
   Register the new service provider by providing the following values. See Configuring Inbound Authentication for a Service Provider for more information on the fields available in this form.
   

   • Issuer: This is the entity id for SAML2 service provider. In this case, you can use travelocity.com.

     This value should be same as the SAML.IssuerID value specified inside the travelocity.com/WEB-INF/classes/travelocity.properties file.

   • Assertion Consumer URL: This is the Assertion Consumer Service (ACS) URL of the service provider. The identity provider redirects the SAML2 response to this ACS URL. However, if the SAML2 request is signed and SAML2 request contains the ACS URL, the Identity Server will honor the ACS URL of the SAML2 request. A sample value for this can be: http://localhost:8080/travelocity.com/home.jsp

     This value should be same as the SAML.ConsumerUrl value mentioned inside the travelocity.com/WEB-INF/classes/travelocity.properties file.

   • NameID format: The service provider and identity provider usually communicate with each other regarding a specific subject. That subject should be identified through a Name-Identifier (NameID) , which should be in some format so that It is easy for the other party to identify it based on the format. There are some formats that are defined by SAML2 specification. Enter the default value of this format here (i.e., urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress).
   • Use fully qualified username in the NameID: Set this as true by selecting the checkbox. A fully qualified username is basically the user name with the user store domain. In short, the username must be in the following format: {user store domain}{user name}. 
   • Enable Response Signing: Set this as true by selecting the checkbox. This is used to sign the SAML2 Responses returned after the authentication process is complete.
   • Enable Assertion Signing: Set this as true by selecting the checkbox. This is done to sign the SAML2 Assertions returned after the authentication process. SAML2 relying party components expect these assertions to be signed by the Identity Server.
   • Enable Signature Validation in Authentication Requests and Logout Requests: Set this as true. This specifies whether the identity provider must validate the signature of the SAML2 authentication request and the SAML2 logout request that are sent by the service provider. 
   • Enable Assertion Encryption: This defines whether the SAML2 assertion must be encrypted or not.
     
   • Certificate Alias: Select wso2carbon here. This is used to validate the signature of SAML2 requests and is used to generate encryption.
   • Enable Single Logout: Set this as true by selecting the checkbox. Do this to ensure that all sessions are terminated once the user signs out from one server.

   • Enable Attribute Profile: The Identity Server supports a basic attribute profile where the identity provider can include the user’s attributes in the SAML Assertions as an attribute statement. You can define the claims that must be included under service provider claim configurations. Also, once you select the “Include Attributes in the Response Always” checkbox, the identity provider always includes the attribute values related to selected claims in the SAML Attribute statement.

   • Enable Audience Restriction: You can define multiple audiences in the SAML Assertion. Configured audiences would be added into the SAML2 Assertion.

   • Enable Recipient Validation: The recipient attribute of a SAML assertion contains the service provider's Assertion Consumer Service (ACS) URL, and the Identity Server, by default, sends the registered service provider's ACS URL as the recipient.

     Tip: There can be situations where the same SAML assertion can be consumed by multiple service providers. A scenario where we use SAML2 Bearer Grant is one such example. In such a scenario the assertion consumer endpoints of all those intended service providers should be added as recipients. Enabling recipient validation allows you to do just that.

   • Enable IdP Initiated SSO: The service provider is not required to send the SAML2 request when this is enabled.

6. Configure claims for the service provider. To do this, do the following. For more information on this section, see Configuring Claims for a Service Provider.
   1. Expand the Claim Configuration section in the service provider form. 
   2. You can select the claims that must be sent to the service provider. If you just want to send them as claim URIs, select Use Local Claim Dialect.
   3. Alternatively, if you want to define new claim URIs for the attributes that are sent, you can define any values for them and map these values with the claim URIs local to WSO2. For example, you want to set the email address of the user as http://testclaims.com/claims/emailaddress claim URI, you can define it here and map it in to http://wso2.org/claims/emailaddress. To specify this, select the Define Custom Claim Dialect option and click Add Claim URI. Enter the Service Provider Claim URIs and select the matching local claim from the dropdown. You can also mark them as a Requested Claim.
       
7. Configure outbound authentication as Default authentication type. This specifies that the identity provider authenticates the users with the username/password by validating with the identity provider's user store.
8. After providing the above information, click Register.

After successfully registering the service provider, log out from management console. The next step is to run the sample.

Running the sample

1. Visit http://localhost:8080/travelocity.com. You are directed to the following page:
    
2. Since you need to use SAML2 for this sample, click the first link, i.e., Click here to login with SAML from Identity Server. You are redirected to the Identity Server for authentication.
3. Enter the default admin credentials (admin/admin).
4. Now you are logged in and you can see the home page of the travelocity.com app.