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
- 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)
- 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.
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.
My LinkedIn profile
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 12:10 PM 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 12:47 PM CET #