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.
The question:
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?
Once Upon a Camayoc 
Mmm. Sounds like an “OSINTOT” question, for federated IDM (where OSINTOT is an acronym coined by an old pal, which stands for “Oh S**t, I Never Thought Of That”).
If there isn’t a neat answer to the question, the threat model for federated IDM needs to have it added – and there could be some very interesting repercussions. While I’m not an expert in this area, I’d suggest that the most immediate workable way to approach the problem would be to implement local blacklisting at newcloudservice.com , as a mechanism intrinsic to the service…
LikeLike