Logging-in from another application (poor man’s SSO)

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

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.

The solution:

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:

When a user clicks a link to the Content Navigator (1), a snippet of javascript evaluates if the user is currently authenticated by requesting a resource on the application server (2). If by any chance a http 200 is issued, the user will be forwarded to the Content Navigator (3), otherwise in case of http 403 (forbidden), a request is made to the portal backend for a new login link.

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.

8 thoughts on “Logging-in from another application (poor man’s SSO)

  1. Hi Ivo Jonker. We are looking for a similar solution. In our case, Content Navigator URL is integrated with all our business applications which are DOT NET and SSO is enabled via SPNEGO. It is working perfectly for all Windows Desktop applications. Now we need similar ingegration via Mobile browser. As SPNEGO is not supported on mobile whenever we open ICN URL from other applications it says SPNEGO is not supported. Can you suggest any reasonable approach that we can follow to implement SSO in mobile from other custom applications

    1. Hmm, that’s a difficult question for me to answer as i’m not too familiar with mobile.

      I guess, that if you don’t have any mobile device management (some support SSO mechanisms), or a VPN that allows / can be modified to forward credentials you’ll – it can indeed be a alternative to leverage the other app’s on your mobile device on which your user is already logged in.

      What kind of other applications do you have running on the mobile? Are those native app’s? Or web-app’s?

      I could think of the following possibilities:

      1. Use your native app to launch ICN url; you’d be able to apply the above mentioned concept.
      2. Use your web-app to either launch the ICN url using the above concept, or sign in the user on the ICN url to get the session cookies for later use.
      2. Use a cookie with a long expiration; but it could introduce risks so be sure to use a complex key, ssl and if possible ip verification

  2. Hi Ivo. Thanks we will try to look into that

    But maybe we can apply your concept and append logged in username in database and generate a token which contains username and append it to ICN url generated.

    However, how can we make Websphere decode which is the username in the ICN URL and use it for authenication since your other post talks about logging in as a common user in case user is not authneticated. Thanks..

  3. Hi Ivo,

    Please guide me on how to achieve this.

    We can generate a token containing user name and append it to ICN URL. But the bigger question is how to identify username from url and authenticate that user.

    Your guide in Poor man’s SSO #2 (on websphere)
    talks about using a common user ex. guestuser in case user is not authenticated. However, I want the user to be authenticated based on username appended to ICN url. Can we user jar file specified by you and use different TAIparameters to achieve this or do we need to modify the code in jar file?

    1. Hi Amit,

      My apologies for not replying sooner, i totally missed your 14-feb reply as i was celebrating my birthday :).

      Anyway, if you’re able to append a token to the ICN URL, then i assume you could also: Store the Token+’corresponding user CN’ in a database. You would then need a TAI, that retrieves the record from the database, checks if it is still valid and collects the stored USER-CN for authentication (steps 10 through 17 in the above image).

      You would however need to implement your own TAI, the TAI supplied in “Poor man’s SSO #2” is too basic for this use-case, but it can easily be modified to fetch the user record from the database.

      I would like to stress though, that it should be the backend-server that generates the token and not front-end service. The backend-service is the one the user cannot influence in terms of hacking/security.

  4. Thanks Ivo for your valuable insight and wishing you a belated happy birthday. Surely, I will try your suggestions to see whether we can achieve this to fit our requirement.

    1. Best of luck! If you end up getting stuck i might be able to create a more concrete sample implementation fitting your use-case. But i’m guessing you’ll come to a solution.

  5. HI Ivo. I have a doubt here. How can TAI translate the email to fully distinguised name? If you don’t mind it will be really helpful if you can share a a more concrete sample implementation you were talking about.

Leave a Reply

Your email address will not be published. Required fields are marked *