CoderCoderCoder

I haven't forgotten to follow up on federated security and WCF. Indeed, it's been quite fun and interesting digging around in it before I do any more write-ups on it. What I thought was going to be a two-part piece on WSFederationHttpBinding will in all likelihood be a four-part piece. WCF: WS-* Federation HTTP Binding (WSFederationHttpBinding), Part 1 Part 1 is an overview and is can be found here . WCF: WS-* Federation HTTP Binding (WSFederationHttpBinding), Part 2 This will cover installing, configuring, and managing a security token service (STS). In the real world, this will probably have already been done by the time you consider WSFederationHttpBinding. (If you have ActiveDirectory, for instance, you're pretty much already done.) But, for the purposes of having something we can play with, we'll need to find, install, configure, and use a simple STS. WCF: WS-* Federation HTTP Binding (WSFederationHttpBinding), Part 3 With part 3 we'll look at connec...

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 orga...