A while back I wrote about single sign-on. While the ability for users to log into multiple systems without actually performing the log-in task is wonderful, until very recently (sometime in 2005 IMHO) single sign-on only existed within a single network. In other words, it was almost imposible to guarantee security if your employees wanted to log directly into your 401(k) vendor account through your web services portal.
Think about how cool that would be. Your employees log into your portal and have access to training, performance reviews, pay statements from your outsource payroll vendor, their personal data, benefits from your outsource benefit vendors… All in one site and all with one log-in. Now that’s a vision.
You might remember a very similar “vision” from previous posts.
(larger readable image here)
All of these things that are traditionally out of network can not be connected seamlessly for your employees. Almost nobody has a 401(k) administration in-house. You use JP Morgan, Fidelity or whoever, and your employees have to go to a separate site and log-in again. Well not with Federated identities. All of those vendors outside your network can now be incuded in your web services platform.
The problem with this is while the technology now exists
Previous Posts in this series:
5 responses to “Web Services part 4: and Federated Identity Networks”
It’s possible and we’re doing it. Folks can go into our intranet-only Portal and sail outside via SSO to our benefit provider’s sites. It was heavy lifting, I assure you, but not rocket science.
The Other Systematic
A great series of HRIS intro’s!
“the other systematic”
That’s really cool. I honestly have no idea how this gets done other than people have written that it’s possible. I also had no idea anyone had actually successfully implemented this.
Very very cool!!!! Especially having read your blog and knowing how complex your environment is.
-Dubs
Implementing SSO across organisational boundaries is very easy if the infrastructure is in place. Essentially what happens is the outsourced vendor sets up their application to authenticate using LDAP. Because LDAP runs over IP all it requires is an IP port to be made available in the client organisations firewall. This way the vendor point’s their application at this LDAP server on the client organisation’s network.
The rest is magic and depends on how seamless you want the connection. With true SSO (ie log on top your network and everything works) the authentication happens in the background between the vendor application and client LDAP server. With partial SSO, ie user is still required to enter the user name and password but these are the same across multiple systems, users are presented with the vendor’s application standard authentication UI which is authenticated again the client organisation LDAP server.
As you said it can be heavy lifting but not rocket science. There are many organisations here in Australia that have done this for ATS’s.
Basically on-point, Michael. In this case we use Siteminder, and thge service providers use a SM plugin on ther web server layer to apture the authentication token from us and communicate that to their LDAP. In our environemtn it also requires a bit of presence in the DMZ to handle cookie handoffs from one domain to another. I think we support 5 or 6 vendors in this manner, including an ASP for one of the point solutions. You have to love complexity!
T O S