Keep a full SSO experience for end-users while migrating a custom SSO product to OpenSSO
By Bert Van Beeck on Dec 16, 2008
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 :
- Deploy OpenSSO
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)
- 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.
- 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.
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.