Wow, that’s a mouthful of a subject. However, an interesting question was posed on exactly that topic by a delegate at a recent identity management conference I attended.
The speaker was promoting the benefits of delegated identity federation for user authentication of a cloud service. In short, allowing a third party to decide “yes, this user is good”, so let them into your service.
How do you revoke a user mis-using the service?
There were a few interactions, as the speaker was outside his comfort zone at this point, and had clearly never been asked about revocation before. Once he understood the question, the response was essentially…
We’d contact the security officer in the remote organisation and tell them the user is behaving badly in my service and ask them to suspend the account.
I am sure that’ll work (not). Let me give an example. I log into “NewCloudService.com” and it asks me to authenticate. I decide use my twitter account. This all works just fine, and I can now access NewCloudService.com.
But I now start to abuse NewCloudService.com. The model proposed is NewCloudService.com would ring twitter and request my twitter account is suspended because I’ve been naughty on NewCloudService.com. I somehow doubt twitter would comply.
I am not sure if the presenter was seriously suggesting this how they would deal with it, or just too inexperienced to handle the question. I hope the latter otherwise it would seem to me to be major design flaw.
In my experience of identity management and user provisioning, thinking about how to de-provision the user when something goes wrong is the best place to start.
If you can get de-provisioning right, provisioning and all the other processes needed seem to fall into place.
What’s your experience in this area?