I'm wondering what strategies people use for reduced sign on with legacy applications and how effective they have found them?
We have an ASP.Net based intranet and own a lot of the legacy applications, but not all. We also have BizTalk and are considering the use of it's SSO engine too.
A good compromise between effort/rework and the convenience of single sign on is to continue to maintain a list of users, privileges, roles etc in the legacy app. Make the changes necessary to automatically log the user into your application based on their user account (usually their Windows or network account).
I'm currently running a couple of applications that use this method of sign on, and it makes them seem more integrated even though they aren't.
Another advantage we've found is that it stops people from sharing passwords to legacy applications. They're much less likely to hand out an admin password that also gives others access to their email or payroll details!
Multiple identity storage per application?
Might not be a single sign on solution, but have you try looking into something that is more targetted solution like MS Identity Lifecycle Manager? It will simplify identity synchronization between applications and it's pluggable as well, meaning you can hook up your own code to do the synchronization between different system. So if you change the identity info (i.e. login info) in ILM portal, you can propagate those to the different systems. Same thing for provisioning and deprovisioning identity. Single point of entry.
I supposed you can use biztalk also for similar thing.
As for truly single sign on solution where you just logged in once and you don't have to login again to different applications. I've yet to find one.
I supposed if your legacy apps has a pluggable identity provider module, it's doable, meaning you can customize the login system to hook up to your single identity source of truth whatever that maybe.
We did two things with legacy accounts. (legacy web based apps)
We first mapped the legacy accounts to their system logon accounts (running in a Windows Active Directory).
A facade logon screen then was applied to over the top of the legacy apps (web based), this would request the AD logon, which would then reverse map to the legacy applications logon account and assign the appropriate rights to the user, using the legacy systems security model. The user received a token for the session which kept the doors open for them.
This gave us the benefit of not having to retrofit legacy apps (for example what would happen is app x only had numbers for ID, and the user uses a windows logon (alphanumeric), and also achieve a psuedo single signon from the client's perspective.
The other option that did make sense was at the new logon screen, it would check multiple repositories of security, so even if the user didn't decide to use their windows logon they could still logon with the legacy account name. Obviously this does have some side effects but can also help ease the transition pain end users sometimes feel moving between systems.
There are also programs like the Citrix XenApp Single Signon which take a totally different approach to the issue.
In addition to Jimmy's points about using ILM, this particular system does allow integration with the AD PCNS (Password Change Notification Service) service, that can be used with ILM (ILM "sees" the password change event and can publish it to other consuming applications / services) to at least ensure that as a user's password changes in one system, it gets reflected into others.