Web Services Federation Patterns: The Attribute Service
A few days ago I participated in an interesting design session about an web Services identity federation solution. A lot of the debate was centered on the use of attribute and pseudonyms services for loosely coupled the security policies or client and services. As my article about Web Services Federated Identity Patterns was published recently on MSDN, I thought I could extract the sections on which I explain those patterns and blog about it so that you don't have to read the entire paper ;)
The use of attribute services is one of the classic derivations of Web Services Federation topologies on which one of the Security Token Services (IP/STS) can't issue tokens with just the information provided by the consumer. In other words, a STS might require more information than the one provided by the client in order to issue the corresponding tokens.
Why in the world would somebody do that? Well, confidentiality and privacy are some of the main drivers for this model in the sense that based on privacy requirements, only a subset of the consumer claims are used as part of the identity information issued by the IP/STS. The remaining consumer claims may be accessible to security entities such as IP/STSs but it should not be propagated to the different consumer applications.
Solution
The attributes needed for Web Services identity federation can be exposed via an Attribute Claim Service which can be invoked from the IP/STS and services on a Trust Domain. Using this service, either the IP/STS or the service itself can request more information about the requestor in order to complete the proper tasks. The following figure illustrates that concept.
Figure: Federation using an attribute claim service
In this scenario the consumer requests a security token from IP/STS-A which issues a security token and the claim set required for Trust Domain A. Then it will present that security token and claim set to an entity in Trust Domain B, which is either the service or IP/STS-B, depending of the federation pattern we are using. In order to complete the federation process, IP/STS-B might need some extra claims that are not included as part of the claim set issued by IP/STS-A. In this case, IP/STS-B would obtain those claims querying the attribute claim service and presenting the security token issued by IP/STS-A and its own security identity. This access is possible because the Trust relationship that exists between IP/STS-A and IP/STS-B allows this last one to present a valid set of claims and security tokens to the attribute service. This last step is required because the attribute claim service is typically part of the trust relationship between the two Trust Domains.
Although optional, the use of attribute claim services is becoming very popular in Web Services federation scenarios. Based on its flexibility, this pattern can be applied in a number of different topologies and is occasionally combined with the pseudonym service pattern. For instance, in some scenarios the attribute claim service and the IP/STS could be the same physical Web Service and in other scenarios they can be implemented as two separated Web Services in order to maximize the flexibility of the solution.