Federated authentication between two Identity Servers

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 :)

Advertisements

User Provisioning between two WSO2 Identity Servers

featured

In this post I shall be explaining how users can be provisioned between two different Identity Server instances.

User provisioning is a process which simplifies the creation and management of users on multiple systems. With user provisioning, when the user is added to the WSO2 LDAP, the system creates user accounts for the user on many different systems,. This eliminates the need for user accounts to be manually created in these systems. In this tutorial I will demonstrate how this functionality can be done between two WSO2 Identity Server instances. So ultimately when a user is added in one IS, the same user will be provisioned to the other.

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

In this example I shall be using two IS instances running locally on two different ports 9443 and 9445. If you need more information on how to change the running ports of WSO2 products, check my blog post on “Changing the Ports of WSO2 Servers

For the purposes of this tutorial, one IS shall be referred to as the Internal IS and the other as the External IS. The internal IS in this tutorial is running on port 9443 while the external IS is running on port 9445. Our ultimate objective is: when a user is added to the internal IS the same user shall be provisioned to the external IS.

Start the two Identity Servers and login to their management consoles and do the configurations as below.

Step 1: Configuring the Internal IS

  • Click on Add under Identity Providers on the left pane.
  • Give a name and expand the Outbound Provisioning Connectors and under that the SCIM Provisioning Configuration.
  • Check the Enable Checkbox and give the Username and Password of the External IS.
  • Give the user endpoint of the external IS, this is by default https://<HOST&gt;:<PORT>/wso2/scim/Users. (This value can also be found by expanding the Inbound Provisioning Configuration of the Resident Identity Provider in the External IS)
  • Give the User Store Domain as WSO2
  • Check the Enable User password provisioning to a SCIM domain checkbox.

1

  • Save the configuration
  • Click on List under Service Providers on the left pane then click on the Resident Service Provider link.
  • Expand Outbound Provisioning Configuration and select the Identity Provider you configured from the drop down menu then click on the plus icon.
  • Then update the configuration.

2

Step 2: Configuring the External IS

  • Click on List under Service Providers on the left pane then click on the Resident Service Provider link.
  • Expand the Inbound Provisioning Configuration and select the userstore domain to provision users to.
  • Then update the configuration

3

Step 3: Testing the provisioning

Now the configuration is complete. Hence when you add a user to the internal IS, the user should get provisioned to the external IS. I have added a user named testuser@wso2.com through the management console to the internal IS, the log entries of the internal and external Identity Servers are given below.

Internal IS

[2016-02-05 16:33:42,181]  INFO {org.wso2.carbon.identity.scim.common.impl.ProvisioningClient} –  SCIM – create user operation returned with response code: 201

External IS

[2016-02-05 16:33:42,092]  INFO {org.wso2.carbon.identity.scim.provider.impl.SCIMUserManager} –  User: PRIMARY/testuser@wso2.com is created through SCIM.

Now if you login to the external IS management console and navigate to List under Users and Roles, you will see that a user called testuser@wso2.com has been added.

Troubleshooting

Sometimes you may get the following error when adding a user to the internal IS.

ERROR {org.wso2.carbon.user.core.common.AbstractUserStoreManager} –  Error occurred while accessing Java Security Manager Privilege Block

This is caused as a result of the new Identity Provider configuration not being saved properly. In this case, first delete the identity provider entry from the Outbound Provisioning Configuration of the Resident Service Provider of the internal IS and Update it. Then delete the Identity Provider from the list of Identity Providers then follow step 1 again.

Hope this helps, do drop a comment if you come across any issues. Good Luck! :)

Changing the Ports of WSO2 Servers

Almost all of WSO2 products are by default configured to run on port 9443. You will run into many instances where you need to run multiple WSO2 products or multiple instances of the same product in the same environment. In these instances the operating ports of the servers need to be changed.

This can be done mainly in two ways:

Method 1: Setting the port in the carbon.xml

Open the <Product_Home>repository/conf/carbon.xml and change the value between the <Offset> tags. It is by default 0, if you change the value to 2, the server will run on port 9445.

Method 2: Passing the port offset during startup of the server

Running the following command with start the server on port 9445.

./wso2server.sh -DportOffset=2

In certain rare instances the port has been hard coded instead of being extracted from the carbon.xml. If you receive a “java.net.BindException”, the best possible way is to run the following command to see if it the port value has been hard coded anywhere and then change them accordingly where needed.

grep -ril “9443”