Ping Identity recently announced the availability of Version 5.1 of Ping Federate in their blog. What caught my attention was that Ping has now also finally added a feature I (and others) call "auto-provisioning" or "federated provisioning". In federated environments, when users from other entities visit your site and gain access to services, it is often necessary to store some local data about these users on your system. In very simple cases, this could be user profile data, such as the colour of the background, but there could be much more information that would need to be stored.
So does this mean that by deploying federated environments, you are getting back to the "silo problem" where you have fragments of identity data floating around? Does this mean that as a service provider you must now store identity information, and accounts, and deal with everything that comes with it - including compliance with complex intermingled laws and directives? Ugh!
Don't panic. In most cases you don't have to - this can usually be avoided through proper design of the federation scenario. So should you avoid storing any data about external users coming into your system from federated identity providers? Well, this would be nice, but is not always practical. So you often end up having to store something about a user that "arrives" at your site from elsewhere through a federation (or your support of user centric identities).
So here are my recommendations, in no particular order:
- Create those "user entries" on the fly - when someone "flies into" your site for the first time through a trusted federated link or an OpenID sign-on, create the user entry then automatically - if it's not already there. Why? Because the alternative would be setting up a synchronisation service, and you really want to avoid that unless you really, really, REALLY have to...
- Avoid storing "personal" data. This will make you resilient against privacy regulations. OK, or at least not expose you any further to them as you already are :-)
- In most cases, you already receive some data about the user together with the sign-on token. Try not to store a copy of that data, but instead just keep the data around for the lifetime of the current session. This might not always be practical or even possible. In that case, if you do store it, make sure you update the information when you receive changed data next time in the token.
- Don't turn the stored data into a "live account" by giving a user the option to store a local password, unless you really have a good reason to do so! (I am actually wondering what would be a good reason to do this and can't think of any!) :-)
If you follow these recommendations, then you can rest assured that you are not creating user accounts. Instead, you are creating "profile entries". These are not to be counted as "accounts" or "identities" when the auditors arrive, because the profile entries themselves don't carry any entitlement per se - you are not authenticating user entries. You are instead just keeping track of, say, a user's preferences. That is a completely different type of animal.
Another good reason, especially for the first recommendation is that you'll be saving yourself a lot of maintenance if you provision "on the fly" as opposed to manage synchronisation links (including the headaches that come with it). Again, the world is not perfect, and you may find yourself with your back to the wall surrounded by synchronisation links that all cry for constant love and tending.
I could go on and on, but instead I'll refer to the presentation "How to efficiently manage external identities" that my colleague Stefan Rohr and I held at EIC 2008. Hmm. Somehow I can't find the link to it. I guess that'll have to be added tomorrow.
Obviously these recommendations come from the use cases that I've been seen or have even been personally involved in. I'd be really interested in YOUR use cases. Do you agree with my recommendations? Did I perhaps overlook anything, or am I just plainly wrong or "not applicable" in some scenarios? Please let me know by either commenting, or if you prefer, email me.