When traditional SSO is not an option (e.g. due to the lack of infrastructure), it still is possible to move between web-applications while sharing authentication.
In this post i’ll share a possible strategy for authenticating a user on a web-applicationg running on websphere, that was send there from another web-applicationg running on PHP/IIS.
The client runs a custom-made intranet website running on PHP in IIS. The portal is pretty basic and requires the user to login using their corporate e-mail account and a password. The portal has it’s own database containing e-mails, no active connection to their LDAP is used.
After they bought Content Navigator licences the client figured it would be a great idea to include certain views in their application – and to be able to link to the application. But unfortunately they’re prompted for a second login every time.
While normally SSO would be a solution, it isn’t due no policy servers e.t.c. exists. The solution is to create a mechanism where the web portal generate’s an identity token that can be used to access the Content Navigator allowing direct access.
The sequence explained:
As the portal backend keeps track of who is currently logged in, it will be able to append a Token to a database (6/7). This token contains a random-unique byte sequence, an expiry date and the current user’s e-mail address. The expiry date is used to make sure the token is only valid for a very short time, the unique token will act as a non guessable ‘secret’ between the portal and the application server.
The portal frontend receives the generated token, and appends it as a parameter to the original requested URL. The url is then loaded in the browser (9/10).
When Websphere receives the request, it will determine that the current user is not authenticated and will try to use the Trusted Authentication Intercepter to authentiate the request(11).
The TAI will fetch the token from the URL parameter and tests it’s validity. If valid, it will translate the associated e-mail to a fully distinguished name for Websphere to authenticate (12-16). Websphere authenticates and handles the request, the user is now logged in.
Unfortunately i wont be able to share the client’s code, but i’d be happy to help you out on a similar solution if you need any directions.