Convenience vs. Accountability – the Federation Spectrum. (Part I)

(This actually started life as one ridiculously long blog post! So I’ve split it into a few parts in the interests of readability.)

Anyone who’s ever taken an InfoSec course has seen the “Security vs. Usability” pendulum – there’s a great big knob with “Security” on one side and “Usability” on the other…if you dial one up, you dial the other down. Two-character passwords that never expire? Highly usable, hardly secure. Thirty-two character passwords that expire every seven days? Arguably more secure, but reduces usability to the point of ineffectiveness.

When we think about federation, a similar pendulum applies, except that I believe it’s a swing between Convenience and Accountability.

Let’s examine. Start with our old friends A. Datum and Contoso. A. Datum has the user accounts, Contoso has the resources, let’s call it a SharePoint site for simplicity’s sake.

In the pre-federation world, Contoso creates a shadow Active Directory account for each A. Datum user that needs access to the MOSS site, and ACLs their MOSS resources accordingly.

Does this ACL-based solution provide…

• Convenience? Not hardly. Inconvenient for the users, who now need to remember multiple usernames and passwords. Inconvenient for administrators, who need to create and maintain duplicate accounts on the resource side of the relationship, and worry about stale shadow accounts lingering because Contoso has no visibility into A. Datum’s de-provisioning process. (I would argue that this last point also decreases the security of this solution.)
• Accountability? Betcha. Contoso’s administrators can state to a certainty which of their resources is accessible by each A. Datum user, because they can report against the perms assigned to the Contoso shadow accounts.

So duplicate accounts suck dead river rats. Users hate them, admins hate them, everybody hates them. We want to fix it. Enter: Federation. Stand up an STS on either side, configure the necessary claims, do the needful to make the Contoso MOSS site claims-aware.

Does this federated solution provide…

• Convenience? Betcha. Convenient for users, since A. Datum users can now access Contoso’s MOSS site using their A. Datum credentials. Convenient for administrators, since Contoso no longer needs to create and maintain shadow accounts, nor do they need to worry about disabling or deleting stale accounts since access is now tied to A. Datum’s de-provisioning process.
• Accountability? Less so. Why? Consider the previous example. A Contoso auditor (internal or third-party) can ask the application owner for a list of users that have access to resources on the MOSS site, and the Contoso admin can use their usual reporting mechanisms to pull a list of shadow AD accounts and their associated perms. So the answer to “Who has access to resource X?” is “The following AD user accounts.” In a federated environment, in which AuthZ is handled on the basis of claims presented by the account partner? The answer to “Who has access to resource X?” now becomes “The following AD user accounts, plus any A. Datum user who presents the following claim assertions…what’s that? No, I can’t give you a list of who those users are.”

For my part, I still think that fed is the better answer, since I’d rather have the security of having real-time de-provisioning to cut off access from partner users who are no longer active with their respective companies.

But the audit question is a real concern, nonetheless. How do we fix it? One assumes that a bunch of collectively-way-smarter-than-me Microsoft Program Managers and developers are working on this problem already, but tune in tomorrow for my random theories on the matter.