Provisioning,  you’re finally being hotly debated!!!   Can’t wait to add my own 2cents.

Ian and Nishant, in debating differences/similarities between Enterprise Provisioning and Federated Provisioning, seem to be forgetting a critical difference between old-school provisioning and federated provisioning — the combination that federated provisioning provides of provisioning and AAA services coming from the same authoritative source and working in conjunction.

For example, Ian and Nishant talk about federated de-provisioning:

The second catch is deprovisioning. The provisioning process hinges on an authentication event. Deprovisioning cannot be activated on de-authentication. This does leave the problem of how to remove accounts when people have left a federation partner. In the approaches we have seen, when a new account gets built it has an expiration date associated with it that gets updated on every login. After some period of time without an authentication, the account is suspended or deleted. Not a bad way to go.

I would beg to differ.  Federated de-provisioning can be activated on de-authentication, in fact that is a major selling point!  There is no reason why an authority could not return a set of claims at the time a terminated user attempts to authenticate to the Relying Party that says (a) do not authenticate, and (b) de-provision immediately.   If the authority is set up to do so, the Relying Party is home free!  The urgent use case has been taken care of (ie abuse), and the non-urgent cases can be dealt with at leisure, because the associated risk is dealt with.  Who cares if it takes a month to actually delete the account, if you can guarantee that should the terminated user attempt to access the resource during that time, a real-time status check will occur and the termination will be discovered?    If a user is terminated and they never try to authenticate to the resource, maybe the account might last to the end of the day, or even the week.  Maybe the end of the month.   Then somebody can run a report, sync a directory, (god forbid) access a mass user management admin console,  run a cron job to do an out-of-band reconciliation, push a message via the ESB, whatever!  This part of the process can be messy in a federated environment, because the authentication and authorization mechanisms no longer exist in silos and can’t be fooled.  Or to be more exact, the real-time aspect of when the user must reliably disappear from the system no longer depends on security aspects, but rather content aspects dictate the business requires in the case where the user’s identity data is being displayed or acted upon by the system itself or by other users.

I would also point out that most Enterprise systems are not going to be amenable to the expiry approach. Having your users disappear out of a system just because the haven’t logged in in a while is just too inexact a process.   Perhaps instead, the expiry date could kick off a workflow to verify the status of the user though.

It’s ironic to think that batch processing could make a comeback – I’ve spent an awfully long time trying to get people out of that mentality :)