SSO - Single Sign On

SSO mechanism is based on token exchange between the components.

The token is conected with user session, SSO server track time validity of the token.

Basic use case is :

1. Login

  • User enters name and password on the portal.
  • Portal sends the name and password to the SSO server.
  • SSO server sends back the token.

2. Calling the application

  • User clicks on link to component page which is on portal
  • Portal includes token to the link
  • Target application verifies token on SSO server

What do you need to know :

1. Where is the service

Actually the service is running on http://prolixportal.prolix-dev.de/IdentityService . You can get also WSDL file from this location : http://prolixportal.prolix-dev.de/IdentityService?wsdl . However we propose to use ESB url for the service which is : http://<portal>/prolixservices/jbi/IdentityService/ .  Please do not call get method on this url, it does not return WSDL file. 

 

2. How to test the service

My favourite tool is SoapUI . In SoapUI just create new project, in context menu for this porject select "Add WSDL from file" and enter the file location of WSDL. Also let SoapUI generate sample requests for the service.

 

 

 Expand the tree to method getToken and open Request 1.  You can edit XML content of the request, in this example only userid and password. Use name and password of any portal user which is exported to ldap.

Modify the URL of endpoint, click "Play" button to submit request. In the response XML you will get a token. You can use this token as parameter for other WS calls , the most probably you will call validateToken and getPersonInformationByToken .

3. Using the service

Use your preffered webservice framework to generate client classes. Adapt your application so it reads request parameter "prolix_sso" - for instance using filter component . Verify this parameter using method validateToken and synchronize your internal user database with info from getPersonInformationByToken .

Notice 

there are several test bed partners on the same set of systems but sometimes you don't want to mix their data. There is field <organization>Procar</organization> in person information just for this reason.