Ayende recently griped about the complexity of Federation and WCF. While I hope I have already communicated my (partial) consent, as well as some additional remarks on the cause of this in the comments, a comment by sig prompted me to write this post as a response. Here’s the relevant part of the quote:
“If I need to do single sign-on with a third party then yeah, the whole federated thing can be stitched in via configuration, but if it’s within my own app…WTF – don’t need it. Already have message / transport level security – what the hell does the rest of it buy you except a bunch of mindless complexity…”
Depending on the scenario, I’d like to disagree. A statement like the above tends to be a self-fulfilling prophesy, but why paint yourself into a corner?
Consider the very simple case where you have a client that connects to a service and uses Windows Authentication for authorization. The only piece of identity data embedded within the request is a set of credentials (Kerberos token), so if the service needs to perform authentication on any user property besides this, it will need to query Active Directory (AD). For something like user name and security group membership, .NET does this automatically, while you’ll need to explicitly query AD about properties such as the user’s manager, phone number, etc.
This scenario is illustrated in this figure:
This is all well and good, and if you can guarantee that your distributed application will live within a single security realm (AD, AD forrest) forever, I agree that you don’t need the extra complexity of Federation (or rather: Claims-based authentication).
However (and you knew that was coming, right?), why are you exposing a service in the first place? Although WCF doesn’t dictate that you have to be service-oriented to use it, it’s always a good idea to consider whether service-orientation could be beneficial, instead of just dismissing it automatically. In many cases, services are created to be interoperable, which means that you can’t predict which clients you are going to have in the future.
If the situation arrives where the service must be exposed to clients from another security realm, the security model outlined above collapses.
The new client exists in its own security realm with its own AD, and while you may trust that organization, they don’t trust you so much that they are going to allow your service to query the user’s properties in their AD. This is where the message/transport security model that sig finds more than adequate starts to crumble fast. Vittorio Bertocci has an excellent post about this subject, so I’m not going to reiterate all his points here.
What it boils down to is that claims-based authentication (and by that token Federation) solves the problem of heterogenous users by letting the relevant security data travel with the request.
This is the reason why I think uninformed dismissal of Federation tends to be a self-fulfilling prophesy: If you stick with Windows Authentication and AD (or other, similar schemes based on local user stores), you may never feel the need for Federation, since you will probably just consider letting external users use your service to be way too much trouble. If you don’t know about claims-based authentication and Federation, it may never occur to you that you could actually implement such a business case fairly easily.
And while you dismiss such a feature as impractical, your competitor is already doing business with their partners using Federation…