WCF: WS-* Federation HTTP Binding (WSFederationHttpBinding), Part 1

Federated security is interesting because it presents such a clear break between a service and the security (authentication and authorization) that protects it. Plus -- and this is the part I find even more intriguing -- federated security allows for trust. We'll look trust a little more in a moment but let's first consider that first point, the clear line between the service and its security.

With federated security, a service requires clients to authenticate using a security token issued by a security token service. It's the security token service that is responsible for authentication and access decisions. Typically, a security token service is within a specific domain, such as an organization, and refers to policies set for that domain.

Where federated security becomes really interesting is when a client in one organization accesses a service in another organization.

In the example above, we have two organizations, Organization A and Organization B. Both organizations have their own security token service (STS). Organization A has a client that wants to access a service in Organization B.

With federated security, there's a level of trust between the STS at Organization A and the STS at Organization B. The STS at Organization A doesn't have to know about the services at Organization B and the STS at Organization B doesn't have to know about the clients at Organization A. The STSes only have to know about each other. Plus, they have to have a level of trust in each other. This trust amounts to something like: When someone presents to me a security token issued by you (another security token service), I trust that you've done the legwork to authenticate the bearer of the token.

With the issue of authentication out of the way, the security token service for the domain in which a service resides need only address the question of access. That security token service will then consult its policies and, if the policies say it's okay, issue its own security token which can then be used to access the service.

Going back to our example, the Client within Organization A wants to access the Service within Organization B. Here's the process, broken into discrete steps.

Step 1: The Client presents its credentials (say, a username and password) to the Security Token Service (STS) within its domain.

Step 2: The STS in Organization A looks at the credentials and determines if they're valid or not. If they are, it then gives a security token to the Client.

Step 3: The Client then takes that security token (which proves the Client has been authenticated) and presents the token to the Security Token Service at Organization B.

Step 4: The Security Token Service at Organization B checks its policies and determines if the client should have access to the Service. If it decides yes, then it issues one of its own security tokens to the client. That security token is good for access to the Service.

Step 5: The Client then presents to the Service the security token it received from the STS at Organization B.

The Service accepts the security token and thus the Client is allowed to interact with the Service.

As you can probably guess, setting all this up is a little more involved than what we've done to date with the other bindings we've looked at (Basic HTTP Binding, WS-* HTTP Binding, and WS-* Dual HTTP Binding). There's where Part 2 of our WS Federation HTTP Binding comes in.