Over the last couple of years SAML has emerged as the defacto standard for federated authentication and authorization. If you are working with a partner the first question is usually "Do you support SAML?".
Incoming SAML makes it possible to essentially outsource the process of authentication and authorization to a business partner. The partner vouches for the identity of the user and you can essentially use this information to give the user access to your system. This solves the run time but in most cases you still need a "back channel" provisioning process. Getting a SAML assertion telling you that the user "msandr01" would like to log in to your application logging is good but most application needs more information to create a working system account.
Nishant Kaushik published a very good four part series of blog postings on this subject about a year ago that I highly recommend. I ran into the problem in a discussion at Wisegate a couple of weeks ago and I am also looking into the problem for a couple of use cases at work.
The use case we talked about at Wisegate was a bank that had outsourced all of their customer facing applications to various vendors. One vendor did retail banking, another brokerage, a third investment banking etc. All of the different vendors had their own user repositories and own SSO solutions so a single bank customer could have multiple logins and multiple passwords and would have to login to each application separately. The business of course didn't like this and wanted an SSO solution.
The true high tech JIT solution would be to use a federated authentication product such as IBM TFIM and do SAML with the apps all in run time. The hub would be truely light weight and not persist any information about the users. A typical user interaction with the hub would look like:
- Take the request from the user
- Figure out which application this user is trying to login to
- Figure out if the user has any account in any of the apps by asking the apps
- Authenticate the user
- Authorize the user
- Create the SAML assertion and send it to the app
- Act as a reverse proxy in the interaction between the user and the app
In theory this is a great idea but there are some practical considerations.
One issue is latency. Given that this is an online person facing transaction the login should ideally not take more than three seconds (or so) and if we end up pushing 10-15 seconds the business will start screaming. The SSO hub and the apps are physically in different places which means that you will get latency even if you have lighting fast machines that process the requests.
Another issue is complexity. This does require quite a lot of bleeding edge technology and there are plenty of things that could go wrong.
In the end the discussion ended with the conclusion that it is probably safer to go for a more conventional approach where user populations of the apps are reconned back to a central repository in the SSO hub using a meta directory product. SAML would still be used to communicate assertions to the applications but this solution is a lot faster and eliminates a lot of the unknowns. This solution pattern is very common among a number of vendors including Symplified.
Not as high tech and cool but is guaranteed to work and won't cause hard to fix latency based performance problems .
I'd say that we could implement this (http://www.qilynx.com/). Counter parties would only need to register their metadata and endoints with the service registry in our private cloud and manage users from there. Applications could be published via our services portal too.
ReplyDeleteWe pretty much do all the heavy lifting on the SAML end...