This documentation is for WSO2 Identity Server 5.0.0. View documentation for the latest release.
Page Comparison - Configuring Single Sign-On with SAML 2.0 (v.28 vs v.32) - Identity Server 5.0.0 - WSO2 Documentation

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleClick here to view vital information when running this sample in WSO2 Application Server
Info
titleWhen running this sample on AS

Both this SSOAgentSample application and WSO2 Application Server contain different versions of the same slf4j jar. As a solution you can select ONE of the following approaches.

  1. Remove log4j-over-slf4j-1.6.1.jar file from travelocity.com.war/WEB-INF/lib directory and deploy.
  2. Modify <AS_HOME>/repository/conf/tomcat/webapp-classloading-environments.xml to resolve the slf4j conflict and restart the WSO2 Application Server. This change is done so as not to expose the org.slf4j.* package from WSO2 Carbon. 

    Code Block
    languagexml
    <DelegatedEnvironment> 
                <Name>Carbon</Name> 
                <DelegatedPackages>*,!org.springframework.*,!org.slf4j.*</DelegatedPackages> 
    </DelegatedEnvironment>

Prerequisites

Configuring the SSO web application

...

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

    Code Block
    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 once you remove the parent entry. Alternatively, Completely replace the contents of the pom.xml file with the following code snippet.

    Code Block
    languagexml
    <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>
  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).

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

    Note

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

Tip: If you wish to change properties like the issuer ID, consumer URL and IdP URL, you can edit the travelocity.properties file found inside the travelocity.com/WEB-INF/classes directory. This sample uses the following default values.

PropertiesDescription
SAMLSAML2.IssuerIDSPEntityId=travelocity.comA unique identifier for this SAML 2.0 Service Provider application
SAML

SAML2.

ConsumerUrl

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

The URL of the SAML 2.0 Assertion Consumer
SAML

SAML2.

IdPUrl

IdPURL=https://localhost:9443/samlsso 

The URL of the SAML 2.0 Identity Provider

If you edit the travelocity.properties file, you must restart the Apache Tomcat server for the changes to take effect.

...

  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.

      Info

      This value should be same as the SAMLSAML2.IssuerIDSPEntityId 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

      Info

      This value should be same as the SAMLSAML2.ConsumerUrlAssertionConsumerURL 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

      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.

...