Federated security allows for clean separation between the service a client is accessing and the associated authentication and authorization procedures. Federated security also enables collaboration across multiple systems, networks, and organizations in different trust realms.
WCF provides support for building and deploying distributed systems that employ federated security.
The following illustration shows an example of federated security.
This scenario includes two organizations: A and B. Organization B has a Web resource (a Web service) that some users in organization A find valuable.
Note: |
|---|
|
This section uses the terms resource, service, and Web service interchangeably.
|
Typically, organization B requires that a user from organization A provide some valid form of authentication before accessing the service. In addition, the organization may also require that the user be authorized to access the specific resource in question. One way to address this problem and enable users in organization A to access the resource in organization B is as follows:
-
Users from organization A register their credentials (a user name and password) with organization B.
-
During the resource access, users from organization A present their credentials to organization B and are authenticated before accessing the resource.
This approach has three significant drawbacks:
-
Organization B has to manage the credentials for users from organization A in addition to managing the credentials of its local users.
-
Users in organization A need to maintain an additional set of credentials (that is, remember an additional user name and password) apart from the credentials they normally use to gain access to resources within organization A. This usually encourages the practice of using the same user name and password at multiple service sites, which is a weak security measure.
-
The architecture does not scale as more organizations perceive the resource at organization B as being of some value.
An alternative approach, which addresses the previously mentioned drawbacks, is to employ federated security. In this approach, organizations A and B establish a trust relationship and employ Security Token Service (STS) to enable brokering of the established trust.
In a federated security architecture, users from organization A know that if they want to access the Web service in organization B that they must present a valid security token from the STS at organization B, which authenticates and authorizes their access to the specific service.
On contacting the STS B, the users receive another level of indirection from the policy associated with the STS. They must present a valid security token from the STS A (that is, the client trust realm) before the STS B can issue them a security token. This is a corollary of the trust relationship established between the two organizations and implies that organization B does not have to manage identities for users from organization A. In practice, STS B typically has a null issuerAddress and issuerMetadataAddress. For more information, see How to: Configure a Local Issuer. In that case, the client consults a local policy to locate STS A. This configuration is called home realm federation and it scales better because STS B does not have to maintain information about STS A.
The users then contact the STS at organization A and obtain a security token by presenting authentication credentials that they normally use to gain access to any other resource within organization A. This also alleviates the problem of users having to maintain multiple sets of credentials or using the same set of credentials at multiple service sites.
Once the users obtain a security token from the STS A, they present the token to the STS B. Organization B proceeds to perform authorization of the users' requests and issues a security token to the users from its own set of security tokens. The users can then present their token to the resource at organization B and access the service.