by Jesus Rodriguez and Joe Klug

Summary: Throughout the last decade, identity-federationtechniques have been a fundamental complement of distributed programmingtechnologies such as COM+ or CORBA. However, it is not a secret that the use ofidentity federation on those technologies never gained a wide adoption inreal-world implementations, mostly due to some of the limitations that thosetechnologies present in terms of interoperability or the use of proprietaryprotocols. Some of those challenges had a big influence on the adoption of Webservices as the architecture style of choice for implementing distributedsolutions. Consequently, during the last few years, Web services has emerged asthe new battlefront for identity-federation solutions. In this article, weexamine several identity patterns, and consider the strengths and weaknesses ofeach model.

Contents

Introduction
Principles of Web Services Federation
Web Services Federation Patterns
Standards
Conclusion

Introduction

The goal of identity federation is to enable resource accessacross completely unrelated security domains by sharing a limited amount ofinformation such as security identities and policies. When it is implemented asan architectural style, identity federation is often positioned as analternative when identity centralization is not a viable solution. In federatedenvironments, clients are able to use a single set of credentials and identityinformation, issued under a specific security domain, to access resources on acompletely different security domain. Behind those simple principles, identityfederation has been one of the most challenging aspects of IT solutions for thelast few decades. However, despite its inherent complexity, the fundamentalidentity-federation concepts have powerful analogies in our everyday lives.Identity documents such as driver licenses, passports, and credit cards arenormally used as the main artifacts of robust identity-federation procedureslike the ones that are used to interact with national institutions, such as, inthe U.S., the Department of Homeland Security and Internal Revenue Service.Obviously, software-based identity-federation solutions present somesignificant differences, as we can’t always rely on humans for resolving andmapping identities. This is precisely the case with distributed programmingtechnologies on which clients and servers need to be able to establish securecommunications across different security domains.

A lot of work has been done in the Web services security andfederated identity fields. As a result, the industry has produced a series ofStandards that represent the fundamental building blocks of Web servicesfederation solutions. Among those Standards, we can list WS-* protocols such asWS-Security, WS-SecureConversation, WS-Trust, WS-SecurePolicy, andWS-Federation, identity-representation languages such as SAML and XACML, andfederation-specific specifications like the ones that are provided by the LibertyAlliance. All those Standards and their implementations can certainly becomevehicles to help us build Web services federation solutions. However, the keyfor successfully implementing those solutions comes down to understanding theprinciples of Web services federation, as well as the patterns and bestpractices (including the correct use of Standards) that can facilitate theapplicability of those principles.

Principles of Web Services Federation

Imagine that you work at a large company. For your last project,you created a set of Web services that expose some business information tomultiple applications. In order to access those services, the differentapplications need to be authenticated against a central directory service thatcontains all the user and application credentials of your domain. Given thatyou were creating multiple services and that the different clients needed touse different credential representations, you decided to remove thedependencies between your services and the authentication mechanisms byisolating those into a separate service, called a Security Token Service(STS), which can be accessed by all the client applications. Once anapplication authenticates to the STS, it will receive a set of security tokensthat can be used as proof of its identity in order to communicate with theservices. In this case, the STS is acting also as an IdentityProvider (IP/STS). Figure 1 illustrates the basic architecture:

Figure 1. Basic brokered-authentication pattern

As part of the authentication process, the IP/STS provides theconsumer with a set of Claims (ClaimSet) that, fundamentally, are a setof assertions about the consumer identity such as Name, Age, or E-Mail Address,which can be used for other security tasks such as authorization and policyenforcement. Additionally, the IP/STS also issues a set of Security Tokens,which can be used to prove the identity of the consumer as well as all theassertions made on the claims. When a service receives a request from aconsumer, it will use both the Security Tokens and the ClaimSet to validate theidentity of the caller as well as to perform other tasks such as authorizationand policy enforcement. This is possible, because the services trust thesecurity information that is issued by the IP/STS. In other words, we can saythat the services and the IP/STS are part of the same Trust Domain.

After a few months of using this solution, your company acquireda business that also provides some Web services by using its own identityprovider. For agility purposes, your management would like to keep bothsecurity environments working independently; but, at the same time, they wouldlike to leverage both sets of Web services in the next generation ofapplications, without having to be concerned with the intrinsic complexities ofthe identity providers. They want to "federate" bothenvironments.

In spite of the obvious advantage of using federation for this scenario,there are some aspects that you should take into consideration to implementthis solution correctly, without affecting the security boundaries of bothTrust Domains. In addition to all of the security requirements of the IP/STS,you need to consider specific aspects of the federation process, such as thestrategies for mapping and preserving identities across Trust Domains,safeguarding the security mechanisms that are implemented on the IP/STSs, andabstracting the federation complexities from consumers and services (see Figure2).

Figure 2. Initial federation challenge

While the use of standards like WS-Federation and SAML state thebasic principles that are needed to implement this solution, no standard canprovide a silver bullet that addresses all of the aforementionedconsiderations. Instead, those answers always rely on our knowledge of Webservices federation patterns and techniques that can be applied to implementWeb identity-federation solutions correctly.

Web Services Federation Patterns

As a result of the evolution of the Web servicesidentity-federation architectures, the industry has produced a series ofpatterns, principles, and techniques that summarizes the experience that isgained through real world implementations. In this section, we will exploresome of those patterns from a pragmatic standpoint, without introducing anydependencies on a particular standard or technology.

Inter-Domain Token Exchange

Context-Problem

This scenario is very similar to the one presented in theprevious section in which a consumer who is living in a trust domain needs tointeract with a service that is developed in a federated trust domain. Theservice accepts only identity information that is issued by the IdentityProvider of its trust domain, which at the same time has no knowledge of theauthentication mechanisms that are used by the consumer application.

Forces

This scenario presents two characteristics that justify using thesolution described in this section:

·        Multiple Identity Providers: For management and scalabilityreasons, your company needs to maintain multiple trust domains using differentidentity providers.

·        Trust boundaries: Services should only accept securitytokens issued by the identity provider of its trust domain. This will keep thesecurity boundaries that prevent any application from interacting with theservice unless it can present the proper security information.

Solution

By using some of the fundamental principles of federation andtrust, we can design a model that addresses the previously explained scenario.The key to the solution is to establish a trust relationship between the twoIdentities Providers, so that security tokens that are issued in one trustdomain can be used in the other. Figure 3 illustrates the basic model.

Figure 3. Basic federation-trust scenario

Initially, the consumer will communicate with IP/STS-A andexpress its intentions of accessing a resource on Trust Domain B. Consequently,IP/STS-A will issue a security token and a set of identity and attribute claimsthat need to be presented to IP/STS-B in order to obtain a new security tokenand identity claims that can be used to access the resource.

This approach keeps the flexibility of maintaining isolated trustdomains, while introducing trust relationships between the IP/STSs tofacilitate federated interactions between services and consumers acrossdomains. Additionally, this model can be extended incrementally in order toaddress more complex federation scenarios.

One of the challenging aspects during the implementation of thismodel is the fact that it introduces a certain level of dependency between theconsumer on one Trust Domain and the IP/STS on the other. For instance, ifIP/STS-B is using certificates as the security token, the consumer applicationmust be able to handle the certificates before it communicates with theservice. In order to eliminate the dependencies between consumers and an IP/STSon a different security domain, we can apply a variation of this pattern,called an intra-domain token exchange.

Intra-Domain Token Exchange

Problem-Context

The scenario for this pattern is very similar to the one that ispresented in the previous section, except that we would like to avoid any dependenciesbetween the consumers on one Trust Domain and the IP/STS on another TrustDomain.

Forces

In addition to the forces that are listed on the previoussection, this scenario presents one difference that is worth highlighting:

·        Different token-claims representation: On a federatedscenario, one of the IP/STSs uses a security token representation that can’t behanded by the consumer applications on the federated trust domain.

Solution

The solution for this scenario is a small variation of the onethat is presented in the previous section. Specifically, the consumer willpresent the token that is acquired from IP/STS-A to the service on Trust DomainB. The service, probably using some sort of interception mechanism, willforward the token to the IP/STS-B for validation. After that, IP/STS-B will usethe mechanisms that are specified in the trust relationship to validate thesecurity token and the claims, so that the request can be processed. Figure 4illustrates this model:

Figure 4. Intra-domain token exchange

Although this model removes the dependencies between theconsumers and IP/STSs on different Trust Domains, it does introduce an extralevel of complexity on the IP/STS—particularly, in the mechanism that is usedto model the trust relationships with other IP/STSs, given the extraconsiderations that are needed for the security token and claims validations.Additionally, from a security standpoint, this model makes some concessionsallowing the services on Trust Domain B to accept messages with identityinformation that has not been issued by IP/STS-B.

The two Web services federation patterns that we have discussedso far can address a large variety of the identity-federation scenarios thatare presented in real-world applications. The main challenge of implementingthose patterns relies on establishing the correct trust mechanisms between theIP/STS. Sometimes, it is not possible to establish a direct trust relationshipbetween two trust domains. For instance, an IP/STS for the credit department ofa financial institution might be issuing identity claims containing informationthat can’t be shared with a partner company involved in the federation process.For those complex scenarios, the use of a third-party component that can modelthat trust relationship is often a good solution.

Third-Party Trust Establisher

Problem-Context

Sometimes, the creation of trust relationships between IP/STSscan present complexities that can derail into a tightly coupled interactionwith the consequent challenges around management and versioning. For thosescenarios, developers should implement a model that, although more complex,provides the flexibility that is required by the trust relationships, withoutaffecting the default behavior of the IP/STS.

Forces

This scenario could present some specific conditions that justifythe proposed solution:

·        Policy change frequency: The policies that regulate theidentity information that is associated with a consumer are constantly changingand, consequently, those changes can influence the policies of the secondIP/STS.

·        Different token-claims representation: Similar to theprevious pattern, there are some scenarios in which the different IP/STSs usecompletely different claim representations, which can make the process ofmapping the claims and validating the security tokens between those servicesvery complex.

·        Loosely coupling IP/STSs: Based on numerous reasons, one ofIP/STS should not have knowledge of the security mechanisms that are used bythe other IP/STS.

Solution

The typical solution for implementing a complex trustrelationship between two or more IP/STSs, without introducing any dependencies,relies on establishing that trust relationship by using a third-party IP/STS toact as the bridge between the other IP/STSs. Figure 5 illustrates that concept:

Figure 5. Third-party STS federation

In this scenario, when the consumer requests a security token toaccess a service in another Trust Domain, IP/STS-A will contact IP/STS-C toissue a security token that will be accepted by IP/STS-B. The security tokenand identity claims that are returned to the consumer will be in the nativeformat that is used by IP/STS-A, but will contain all of the necessaryinformation to guarantee its use on Trust Domain B. After that, this model willfollow one of the token-exchange patterns; and, when the token is received byIP/STS-B, it will contact IP/STS-C to enforce the trust relationship.

One of clear advantages of this pattern is that it isolates thecomplexities of the federated environment from the different trust domains. Asa disadvantage, this model introduces a new complex component that needs to beversioned and maintained as part of this infrastructure.

Like the first two Web services federation patterns, this onealso requires propagating identities across Trust Domains. Some scenarios willrequire that the IP/STS in one Trust Domain should not have access to theidentities of another. In this case, a pseudonym claim service can be used tomap identities across federated domains.

Pseudonym Claim Service

Problem-Context

Federation scenarios quite often require identity mapping betweenentities that are deployed in different Trust Domains. In some scenarios, theprivacy requirements dictate that the identity should not be propagated acrossdomains.

Forces

This scenario presents several considerations that justify thesolution proposed in the next section:

·        Identity protection: For some scenarios, the IP/STS of aTrust Domain should not have access to the principal identity of the entitiesof a federated Trust Domain.

·        Identity mapping: Although the identity should be protectedacross federated domains, these domains still need a mechanism for identitymapping.

·        Identity collision: For some scenarios, the identity ofservices within an IP/STS can collide with other identities in a federatedTrust Domain.

Solution

A pseudonym claim serviceis a service that maps principal identities to pseudonyms that can be used inthe federation process with different Trust Domains. Figure 6 illustrates theconcept of the pseudonym service:

Figure 6. Federation using a pseudonym claim service

Initially, the consumer requests a security token from IP/STS-A,which, in turn, gets its identity aliases from the pseudonym service. Afterthat, IP/STS-B generates the claims and the security token by using theconsumer pseudonyms, instead of the principal identity. From there, the processcan continue using any of the patterns that are explained in the previoussections.

The fact that we are using aliases instead of the principalidentities preserves identities within their Trust Domains. Also, given thatthe aliases are applied on the initial claim set, the identity-mappingprocesses can be executed against the aliases without any impact on the normalprocess. Although this pattern is focused on pseudonyms for requestoridentities, you can think of variations that use other types of identityaliases, such as service pseudonyms.

Until now, we have explored scenarios in which the securitytokens and claims that are issued by the IP/STSs contain all of the informationthat is needed to execute federation tasks, such as identity mapping and policyenforcement. In practice, this is not always the case, and there are manyscenarios in which the federation procedures need more information than what iscontained in the claim sets that are issued by the IP/STS.

Attribute Claim Service

Problem-Context

Some of the federation tasks require extra information about therequestor that is not included in the security claim set that is generated bythe IP/STS. For instance, the services on a specific Trust Domain require ane-mail claim that is not part of the claim set that is generated by thefederated IP/STS.

Forces

Some of the following details justify the solution presented inthis section:

·        Privacy: Based on privacy requirements, only a subset ofthe consumer claims is used as part of the identity information that is issuedby the IP/STS. The remaining consumer claims may be accessible to securityentities such as IP/STSs, but should not be propagated to the differentconsumer applications.

Solution

The attributes that are needed for Web services identityfederation can be exposed via an Attribute Claim Service, which can be invokedfrom the IP/STS and services on a Trust Domain. Using this service, either theIP/STS or the service itself can request more information about the requestorin order to complete the proper tasks. Figure 7 illustrates this concept:

Figure 7. Federation using an attribute claim service

In this scenario, the consumer requests a security token fromIP/STS-A, which issues a security token and the claim set that are required forTrust Domain A. Then, it presents that security token and claim set to anentity in Trust Domain B, which is either the service or IP/STS-B, depending onthe federation pattern that we are using. In order to complete the federationprocess, IP/STS-B might need some extra claims that are not included as part ofthe claim set that is issued by IP/STS-A. In this case, IP/STS-B would obtainthose claims by querying the attribute claim service, and presenting thesecurity token that is issued by IP/STS-A and its own security identity. Thisaccess is possible, because the trust relationship that exists between IP/STS-Aand IP/STS-B allows the latter to present a valid set of claims and securitytokens to the attribute service. This last step is required, because theattribute claim service is typically part of the trust relationship between thetwo Trust Domains.

Although optional, the use of attribute claim services isbecoming very popular in Web services federation scenarios. Based on itsflexibility, this pattern can be applied in a number of different topologiesand is occasionally combined with the pseudonym service pattern. For instance,in some scenarios, the attribute claim service and the IP/STS could be the samephysical Web service, and, in other scenarios, they can be implemented as twoseparate Web services in order to maximize the flexibility of the solution.

Defederation

Problem-Context

Web services federation solutions are typically complex modelsthat involve a relatively large number and variety of services, consumers, andidentity providers. In that context, the governance and management of the entitiesthat are involved in the federation is absolutely vital to the correctfunctioning of the model. Specially, the ability of dynamically “defederated”entities can become a big challenge in these scenarios.

Forces

The following conditions justify the solution that is proposed inthis section:

·        Defederating services: When a service is removed from thefederation, we need the mechanisms for dynamically updating the IP/STSs andother services in the federated Trust Domains that have a relationship withthat service.

·        Defederating consumers: When a consumer is removed from thefederation, we need the mechanisms for notifying the federated IP/STSs that theidentity claims of that consumer are no longer valid in the federation.

·        Updating policies: When the security policy of a servicechanges, we need the mechanisms for propagating those changes to the federatedIP/STS.

Solution

Undoubtedly, the process of defederating entities is one of themore challenging aspects of Web services federation solutions. An interestingway to approach this problem is to provide the entities that are involved in afederation with a publish/subscribe “defederation protocol” that can be used asthe main mechanism for defederating entities. For instance, when a service isremoved from the federation, a “Defederate Service” message is sent to theIP/STS of its Trust Domain and, from there, propagated to the IP/STSs and otherservices that are involved in the federation. After that, a consumer from adifferent Trust Domain application will be unable to acquire a token to accessthat service. Figure 8 illustrates this concept:

Figure 8. Defederate service model

Indirectly, the use of a defederation protocol helps to enforcethe security and trust boundaries that are enforced in the Web servicesfederation solution. As explained in the previous section, there are multipleaspects that can be implemented with the use of a defederation protocol,without interfering with the normal functioning of the Web services federation.

Standards

During the last few years, the Web services community andsoftware vendors have produced some standards that address some of the most commonchallenges of Web services federation. Although the patterns that are presentedin the previous section are not dependent on a specific standard, certainlymost of the practical implementations are based on some of them. The basic setof Web services federation standards are based on WS-Trust and WS-Federation.WS-Trust is a great solution for implementing brokered-authenticationscenarios, as it provides mechanisms for codifying claims (assertions) about aconsumer as security tokens that can be used to protect and authorize Webservices requests in accordance with a policy. WS-Federation extends that modelby describing how the claim transformation model that is inherent in securitytoken exchanges can enable richer trust relationships and advanced federationof services. Although both WS-Trust and WS-Federation rely on WS-Security and,consequently, can use multiple security token representations, the use of theSecurity Assertion Markup Language (SAML) can considerably improve theflexibility of a Web services federation solution. SAML provides a natural wayof expressing identity assertions (claims) and other metadata information thatcan be exchanged between the different entities on a federated environment.Finally, the Liberty Alliance project and, specifically, the ID-FFspecification propose a very pragmatic approach that facilitates theimplementation of federated identity scenarios. Although there is some overlapbetween the WS-* protocols and the Liberty Alliance project, there are lessonsand best practices that can be leveraged from both in order to implement robustWeb services federation solutions.

Conclusion

These patterns for solving Web services federation scenarios arebased on real-world experiences. This is not an exhaustive list; these patternssolve the most common identity-federation challenges. Each pattern evolved, asthe requirements for Web services federation grew more complex. Even thoughthey have been distilled to their most basic model, they do not have to beimplemented as stand-alone models. Several patterns can be combined to solveeven more complex requirements. Understanding these patterns and the principlesof Web services federation improves the correct use of Web services federationstandards and technologies. Over time, these patterns will evolve and newpatterns will emerge to keep up with the ever-changing landscape of identityfederation.

About the authors

Jesus Rodriguez is the Chief Architect of Tellago Inc. Heis also a Microsoft BizTalk Server MVP, an Oracle ACE, and one of a fewArchitects worldwide to be a member of the Microsoft Connected Systems Advisorteam. As a member, Jesus has been selected to participate in a variety ofSoftware Design Reviews with Microsoft’s Product Teams including WindowsCommunication Foundation, Windows Workflow Foundation, and BizTalk Server.

Jesus derived his extensive experience with business processintegration and messaging through numerous implementations of disparate systemsfounded on the principles of SOA and BPM. Jesus is an active contributor to the.NET and J2EE communities and an internationally recognized speaker and authorwith contributions that include several articles for various publicationsincluding MSDN Magazine, Microsoft Architecture Journal, SOAWorld,and Web Services Journal, as well as speaking engagements at topindustry conferences such as Microsoft TechEd, SOAWorld, Microsoft SOA and BPMConference, Oracle Open World, Web Services Security Conference, and theMicrosoft MVP Summit. Additionally, Jesus has conducted a number of Webcasts onvarying SOA technologies.

Jesus is a prolific blogger on all subjects that are related toSOA, and has a true passion for technology. You can gain valuable insight onleading-edge technologies through his blog at http://weblogs.asp.net/gsusx.

Joe Klug is the Chief Technical Officer at Tellago Inc.Joe has an extensive background in enterprise application integration andbusiness process management, which he derived though practical consultingengagements and enterprise-scale software development.

Prior to Tellago, he worked as a Product Manager in the BizTalkServer team at Microsoft Corporation. During his six years at Microsoft, Joewas a key contributor on several releases of BizTalk Server. Some of his keyareas of responsibility include Web services integration and adapterdevelopment, and he was one of the founders of the software development kit fordeveloping Windows Communication Foundation-based adapters.

While at Microsoft, Joe became a nationally recognized speakerthrough engagements at Microsoft conferences including TechEd, SOA & BPMConference, Office Developers Conference, and SharePoint Conference. He alsoworked as an interoperability consultant at J.D. Edwards, focusing onintegrating J.D. Edwards OneWorld software to other third-party applications,mainframe solutions, and e-commerce gateways. Joe received a Bachelor ofScience in Computer Science from Michigan Technological University and anM.B.A. from the University of Colorado.

Joe shares his insights on technology through his blog at http://geekswithblogs.net/jklug/Default.aspx.

This article was published in the Architecture Journal, a printand online publication produced by Microsoft. For more articles from thispublication, please visit the ArchitectureJournal Web site.