More Things about Federated Provisioning
My previous post on federated provisioning generated some interesting responses, both in the comments and in the blogosphere (see responses from Ian, Pamela and Pat Patterson). The topic has been so engaging (starting with Jackson Shaw’s post) that while I was writing this post I saw that Dave Kearns has made it the topic for a series in his newsletter.
Pat’s post is definitely worth a read as it describes how Liberty Alliance has proposed a solution to the thorny issue of data exchange between the two parties in the case of Scenario 2: Just-In-Time Provisioning. It sounds like an elegant solution, especially since it solves the issue Karl brings up in the comments to my post regarding not overloading the SAML assertion with extraneous information. Would love to hear if anyone knows of any issues in the solution.
Ian and Pamela also discuss the issue of federated de-provisioning, which has also been a thorny issue in federation discussions. Pam talks about being able to initiate de-provisioning when a user who should no longer have access tries to authenticate. That is certainly one way to do it. But more often than not, de-provisioning cannot be initiated during an authentication flow because the reason the user should no longer have access is that they are no longer employed at the company they got federated from. Meaning: they cannot authenticate from the RP in the first place.
What harm then, is there in a federated account sitting around if it cannot be authenticated to? Well, the answer I usually get (from customers) is that in the reality of today’s systems, creating federated access to a service often involves creating some sort of account in an underlying legacy system. An account that can be authenticated to outside of the federation context, albeit only from a back-channel. While this is a scenario less likely to get abused, it is nonetheless a scenario that security audits frown upon, and that get flagged for remediation as a compliance risk.
So what to do? Ian talks about expiring accounts that have not been accessed in a while. Out-of-band de-provisioning between the RP and the SP is also a possible option, as described by Pam. That makes the overall integration between Acme and Omega a blend of Scenario 1 and 2, where federated provisioning happens just-in-time, but de-provisioning happens out-of-band (probably on a periodic basis) through a well-defined interaction. The de-provisioning can be made real-time as well, in that the provisioning server at Acme can issue a de-provisioning SPML request to the provisioning server at Omega, just like it would to any internal system, when the user is de-provisioned at Acme.
As you can see, solutions abound, and customers can choose the one that suits their needs the best. So it is pretty obvious that it is possible to solve the federated provisioning/de-provisioning problem. The issue is that none of this is standardized or formally productized in any way, and is left as an exercise for the customer to solve (Translation: Costly integration problems when different vendor products are involved). And where this issue was a costly annoyance in federation deployments between businesses, SaaS (where this whole discussion started) takes this to a whole new level, creating a barrier for adoption.
But as Pat says “Seems like that might change now…”
About The Author
Hi Nishant,
I was wondering about the business side of this equation, namely how many companies provision to SaaS apps today. Granted, not all SaaS apps are created equal and some don’t even have a interface for provisioning but… I created a poll on LinkedIn at http://polls.linkedin.com/p/26723/ojkhm to capture results.
We’ve got a blog now but it doesn’t have RSS just yet. Stop by and say hello!
Nishant:
A comment on the federated provisioning discussion that might be relevant… beyond the technical approach is also de SLA, and come to think about it, the liability implications. As you rightfully stated, for the most part federation hinges, in a practical way in local accounts at the RP being created and linked to the federated identity, which, if left dormant might create a potential thread. In my view this has a few implications, such as 1) the obvious one that you pointed out: dormant accounts can be exploited albeit through backdoor channels — that’s a strong reason to deal with them; 2) they used up digital space in systems and also in themselves, they represent a potential asset that could be exploited/abused, thus opening up potential privacy issues, simply on the data that the record itself is made up; 3) As someone pointed out, in SaaS environments, organizations are often charged based on the number of users from their end that are registered for the application, so there is a cost implication (not to say that simply keeping data around wouldn’t in itself represent a cost), but this may also have liability implications to either the RP or the IdP, in the event that any of the above situations occurred, who is responsible for the potential damage caused? Is there an SLA or a clause somewhere that specifies how this is to be dealt with when things do go wrong? I propose that these elements, which are part of a federated identity network be addressed up front as the federation itself is being established, such that parties know what their responsibilities and liabilities are in the exchanges.
It is appropriate to refer to Bob Blakley?s work on relationships at this point, which to me is the basis for how trustworthy federation will take place. If you come to think about it, an effective way to ensure that accounts are terminated in a relatively timely fashion is to see that one of the parties, RP or IdP see an incentive in keeping the relationship up-to-date, and provided that they have the practical means to do so, there is a much higher chance that they will.
Another relevant observation comes from the world of identity assurance ?
if identity assurance is a continuum, a watermark so to say, over time, and particularly in a federated network, it will tend to decay over time unless it is refreshed and updated. This is why in many federated networks (particularly those that have a heavy heritage from PKI), the elements of expiration and renewal are so critical. This is a mechanism by which parties have a worst case metric for containing the level of decay (smells funny, doesn?t it?) of federated identities.
I have been working since 1998 on “agreement driven provisioning” models that have been around in the telco space for a long time, this is to say that agreement lifecycles – the legal binding of relationships for a finite period of time make a good common agreed place for federation systems to sync – especialy in terms of de-provisioning / re-provisioning in sync with the agreement lifecycle