Keep a full SSO experience for end-users while migrating a custom SSO product to OpenSSO

Ever seen a customer ask the following ?

We have a custom made Web-SSO solution, and would like to migrate to OpenSSO.  How can we do this in an application by application fashion, by having the 2 solutions coexist during the migration phase ?The easy answer would be : use federation.  But the lack of federation capabilities may very well be the reason why they want to move to OpenSSO, or the customer may not want to spend money by adding federation functionality to a product that is about to be phased out.

So how do you do it ?
There are a couple of scenario’s to do this, but one scenario may be the easiest :

  1. Deploy OpenSSO

  2. Protect OpenSSO as you would protect any web application with the old SSO solution. (this can be done by an agent, proxy, or any other way it was done in the past)

  3. In OpenSSO, create and deploy a zero-page custom authentication module. This is a very simple authentication class getting the userid from the HTTP header, allowing  the userID to be used later by OpenSSO when starting the session. At this point, there is no need to verify the password, as that was already done inside the old SSO environment.
As a result the following is true :
  • Applications still connected to the old SSO environment will be authenticated the old-fashioned way.

    If however the end-user moves to an already migrated application, that application will request the identity from OpenSSO.  As there will be no session inside OpenSSO yet, OpenSSO will start it's own authentication via the above described zero-page fashion, (thus by receiving the userid from the old SSO solution - received when OpenSSO redirects forward and back to the old SSO solution when handling its own protection)
  • In the event a user starts with an already migrated application, he/she will be redirected to OpenSSO for authentication. As OpenSSO is protected by the old SSO solution, authentication will be required inside the old SSO solution meaning that the user is redirected once again to the old SSO solution. Once authenticated there, the user will be redirected back to OpenSSO, the userid will be used for the session (via f.e. the HTTP header), and the application will be given the correct userid by OpenSSO. The end-user can now freely move to application not migrated yet, as the session already exists in the old SSO solution.

Therefore, the experience for the end-user is full SSO between migrated and not-migrated applications.

When the migration is completed, OpenSSO can be configured again not to be protected by the old SSO solution, and the new authentication modules can be activated replacing the zero-page authentication module.
That way, all migrated applications will be served by OpenSSO and the old SSO solution can be removed.

Comments:

Hi,
If suppose we want to establish sso between other sso product(not webapplication).Then opensso support for that.

Posted by praveena on February 27, 2009 at 04:10 AM CET #

Hi Preevana,

typically opensso is deployed for webapplications.
That said, since the release of opensso 8.0, there are quite a few options one can go for to integrated fat-clients into opensso for SSO.
OpenSSO now comes with REST interfaces to do authentication, authorisation, attribute query and logging that can be leveraged by fat clients to connect.
Also, SOAP interfaces are available too.
What you need to do however is provide your own authentication forms/screens in your applications, but then you can let opensso take care of then actual authentication.

Posted by Bert on February 27, 2009 at 04:47 AM CET #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Bert Van Beeck is a Senior Software Architect at Sun Microsystems, specialized in Sun's Identity Management portfolio. He's part of the Northern European pre-sales software team.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today