Federation Agreements

Brian Puhl has a very lucid post at http://imav8n.wordpress.com/2008/07/20/federation-agreements/ regarding identity federation at Microsoft, and the nature of the agreements made between federating organizations. If you are contemplating establishing an identity federation with another company, you should read it.

Federation requires some level of trust (the social kind) between organizations. When you allow federated identities access to your resources, you trust the federating organization to manage their identity information in a way that is consistent with the security you require for those resources. Note that this is NOT the same as saying they should manage their identity information to the same level that you do. For instance, just because you require 10 character passwords for your Active Directory accounts, it doesn't imply that you should require your federation partner to do the same. Why not? There are two reasons:

1. First off, as Brian says, what you are really buying with federation is more accurate provisioning and deprovisioning of access to your resource. You have a choice in the matter. Your first choice is to manage your partner's identity information on your own systems. This is expensive, AND you have to accept the risk that you will not will not provision or deprovision the identities accurately or in a timely fashion. How are you going to know when someone in your partner's organization leaves or changes roles and needs to have their identity information updated?

The alternative is to use federated identities, and let your partner take the responsibility of proper provisioning and deprovisioning. Presumably they are in a better position than you are to do this. BUT, you have to accept the way that they manage their identities internally.

If the residual risk associated with managing the identities yourself (plus the cost factor) is greater than the residual risk associated with using federated identities, then federation makes sense. That's the real tradeoff that you are making.

2. The other reason you don't require your partner to manage their identities the same way that you do is that presumably your AD identities provide access to lots of things in your organization; perhaps everything. The risk associated with your AD accounts is therefore potentially very high, so you require strict controls. But the identities you trust from your partner will only have access to the specific resource that accepts those federation claims. The risk associated with compromising that resource is likely much smaller than the risk associated with the compromising all of your internal resources.

As Brian says, it all comes down to managing risks. But you have to understand what the risks really are before you can manage them.

Comments are closed