Convenience vs. Accountability - the Federation Spectrum. (Part II)

When we last spoke, we talked about the inherent trade-off between Convenience and Accountability in a federated environment (A. Datum has the users, Contoso has the SharePoint site, or some other resource.) Another way to think of this is the trade-off between “Making your users and admins happy” versus “Making your auditors happy”.

So now that I’ve ranted about the problem, how would I go about fixing it? The issue that’s up for debate here, is determining how Contoso will be making its authorization decisions.

(In fairness, I can’t claim original credit for much of what follows: Brian has been talking about this for awhile, including at the last TEC conference in Vegas. So consider this my sermon based on I Puhl 2:1-15 or something. :-))

So in the original shadow account configuration, Contoso made its AuthZ decisions on a user-by-user basis: bob@adatum.com’s shadow account had access to certain resources on the basis of individual- or group-assigned ACEs. Very granular auditing, but difficult to configure and maintain from both a user and admin perspective.

In the federated configuration, Contoso now makes AuthZ decisions on a claim-by-claim basis: A. Datum users who present the “Marketing” claim have access to certain resources, based on the resource partner-side perms assigned to that claim. Provides SSO and tight control over the de-provisioning process, but audit trails become less informative.

How, then, does Contoso regain the usefulness of its auditing process, without giving up the SSO and good de-prov that federation provides? Somehow, some way (we’ll get to my theory on how, tomorrow), Contoso needs to get back to making AuthZ decisions on a user-by-user basis: bob@adatum.com’s federated login ID has access to certain resources on the basis of individual- or group-assigned perms. Only instead of assigning perms to an AD shadow account that needs to be managed and configured (and badly de-provisioned) on the resource partner side, these perms will be assigned to the originating account partner login, which has been authenticated by the account partner through the existing federation agreement. So rather than the A. Datum users bringing their authorization with them in the form of claims? A. Datum users will only bringing their authentication information with them: Contoso still trusts that an A. Datum user is who he says he is since, he has been authenticated by the federation partner (and A. Datum users will still lose access to Contoso resources when they are de-provisioned on the A. Datum side). But Contoso will be making its own authorization decisions about who gets access to which of its resources, thankyouverymuch.

Here’s the rub: if we move into this kind of model, we have effectively re-introduced a provisioning problem on the Contoso side…these partner identities need to be recorded and maintained in some efficient way, in order for Contoso to be able to make meaningful user-by-user AuthZ decisions without losing the inherent SSO and de-prov benefits afforded by federation. (Otherwise we’re right back where we started with shadow accounts, and deploying fed has bought us nothing.)

Tomorrow? The thrilling conclusion, wherein Laura posits a potential solution to the newly-reinstated resource partner provisioning issue.

Carry on.