> Archive > Issue XXXIX: May 2010 > Understanding Service Composition, Part II: Dealing With Identity
John deVadoss

John deVadoss


John deVadoss leads the Patterns & Practices team at Microsoft. His responsibilities include platform and architecture strategy for the developer tools and the application platform. He has over 15 years of experience in the software industry; he has been at Microsoft for over 10 years, all of it in the enterprise space – as a consultant, as a program manager in the distributed applications platform division, as an architect working with some of Microsoft’s key partners, director of architecture strategy and most recently leading technical strategy for the application platform.

Prior to Microsoft he spent many years as a technology consultant in the financial services industry in Silicon Valley. His areas of interest are broadly in distributed application architectures, data and metadata, systems management and currently on edge architectures (both services and access), but most of all in creating business value from technology investments.

John has a BE in Computer Engineering, and an MS in Computer Science from the University of Massachusetts at Amherst, where he also did graduate work towards a PhD in Computer Science - which he hopes to complete at some point in the future.


rss  subscribe to this author


Understanding Service Composition, Part II: Dealing With Identity

Published: May 12, 2010 • SOA Magazine Issue XXXIX


Services often enforce a trust boundary. A service typically does not trust another external service and will do its own due diligence with respect to granting access and execution privileges to service requests. Incoming messages will be inspected; fields will be validated; identity will be authenticated, and entitlements will be validated prior to allowing incoming service requests to be processed. There is typically a workflow of tasks that is prescribed prior to fulfilling external service requests:

  • Authentication (validating the identity of the incoming service request)
  • Authorization (validating the right to access resources and business functions)
  • Auditing (recording and tracking who did what and when)

In this context, dealing with trust and identity across multiple services is essential and commonly a pre-requisite to enabling service composition in the real world. A lack of a first-class emphasis on dealing with identity across multiple services leads to identity and access management becoming a challenge and often a hurdle for realizing service-oriented architectures.

How does this challenge manifest itself? Let us consider a self-service application scenario inside a medium-sized organization. Building a service-oriented employee self-service portal will involve composing services exposed by the payroll application, the 401k application, the employee performance application, the benefits application etc. Often these are disparate and autonomous applications with their own identity profile and their own authorization realms, which can lead to some interesting challenges with respect to dealing with identity and access management.

  • Single Sign-on (SSO) - the ability to login once and obtain access to multiple services, even though they may be exposed by disparate systems. (For example, ensuring that employees do not need to sign-on multiple times; separately for every single constituent service that they want to access.)
  • Federation - the ability to delegate responsibilities such as authentication across multiple parties or organizations. (For example, the 401k application may be outsourced externally by an enterprise; however, employees would want to be able to access their accounts without having distinct, separate logins.)
  • Entitlements - the ability to manage the rights associated with the user. (For example, the self-service application needs to recognize an employee in the HR department and enable distinct privileges that are usually not available to someone that may not be part of the Human Resources business unit.)

Key Concepts

Single Sign-On

When an end user is accessing a self-service portal that composes multiple services, and is forced to sign-on multiple times to each of the individual, constituent services, it leads to a very poor user experience; furthermore, it increases complexity for the end user and for IT, increasing cost for everyone involved.

Single sign-on is the ability to login once and obtain access to multiple services, even though they may be exposed by disparate systems. In the real world, working with service-oriented architectures, there are a few common categories of single sign-on scenarios (web single sign-on, operating system integrated sign-on and federated single sign-on).

Web single sign-on refers to the scenario where web applications and web services enable a shared, common single sign-on for their end-users. In this model, unauthenticated users are redirected to a specific pre-determined website to enter their credentials and to login. On completion of successful authentication, cookies are issued and stored and then subsequently used by the web applications and web services to validate the authenticated end user sessions. Windows Live ID is an example of shared, common web single sign-on.

Operating system integrated sign-on refers to the scenario where authentication is performed by authentication capabilities directly built into the operating system, whether Windows or UNIX or related flavors. Integrated Windows authentication (Kerberos or NTLM) is an example of operating system integrated sign-on.

Federated sign-on refers to the scenario where the authentication responsibility is delegated to a trusted third party or service. End users will not need to be prompted to sign-on as long as he/she has been authenticated by a trusted, federated authentication service. Kerberos is an example of a technology that enables federated single sign-on.


Federation is related to single sign-on in that it enables a type of single sign-on; but, it is not restricted to just single sign-on. Federation implies delegation of responsibilities honored through trust relationships between federated services or parties. Authentication is only one type of responsibility that may be delegated to a different party; Authorization is another common responsibility that may be delegated to a trusted third party, as are analytics, and logging etc.

Service-oriented federation protocols are used by the federating parties to communicate with one another. Since federation implies that a responsibility is delegated to and executed by a different service or party, these protocols enable identities to obtain tokens from a trusted, third party (identity provider or security token service) that then enables the validation that a given identity has been authenticated and is entitled to a set of rights and privileges.

In the real world, it is not unusual to have sophisticated, often complex, trust relationships involving multiple organizations and business entities. Some common trust relationships are as follows:

  • Hub-and-spoke
  • Hierarchical
  • Peer-to-peer

In the hub-and-spoke approach there is a broker that manages trust centrally and that is directly trusted by the federating services or parties. This eliminates the need for services to manage their own trust relationships. The Kerberos model is a special instance of the hub-and-spoke model based on the Kerberos authentication protocol. Similarly, the security token service (STS) provides another special instance of the hub-and-spoke model with the STS playing the role of the central broker.

In the hierarchical approach, two services or parties have an indirect trust relationship if they both have a trust path in their respective branches in the hierarchical tree to a shared, common root authority. Supply-chain ecosystems provide a good example of this model in the real world, where a primary supplier is trusted by secondary suppliers, who are in turn trusted by tertiary suppliers and so on. It is common for the hub-and-spoke model and the hierarchical models to co-exist in the real world.

In the peer-to-peer approach, trust is represented as a collection of ad-hoc 1:1 relationships. Applications such as LinkedIn and Facebook enable trust relationships, based on professional and personal relationships between individuals, and serve as good examples of this trust model.

Again, in the real world, it is not unusual to find hybrid models, usually comprising more than one of the above-mentioned trust models.

User Entitlement and Authorization

Entitlement management broadly refers to the collection of capabilities used to grant and revoke access rights and privileges to identities (users, groups etc.), in accordance with the restrictions and policies of the organization and the needs of the business. The process of enforcing access rules and policies at run-time is usually referred to as authorization. Authorization is closely associated with entitlement management, and colloquially, the two terms are often used interchangeably and in place of each other.

Within a service-oriented architecture, authorization can be enforced at more than one tier, and also at multiple layers within a tier. At a coarse-grained level, only users in the HR organization may be allowed to access the Performance History service, for example. Within the Performance History service, there are likely to be fine-grained rules and restrictions that enable access only during the performance review periods for instance. Furthermore, at the workflow and the data layers, there might be restrictions and filters that, for example, might exclude access to performance data belonging to executive employees and so on.

Service-oriented architectures often use a combination of role-based and rules-based authorization to determine and enforce user entitlements for an identity.


So far in this section we have discussed some of the concepts underlying the challenges with respect to dealing with identity and service composition. Let’s now shift gears a little bit and delve into a concept that serves as the key enabler for addressing most of the challenges discussed.

The concept of a claim is used to enable a very powerful abstraction for identity and access control across multiple services.

Almost all of the commonly used approaches for managing authentication and authorization are based on two fundamental concepts - a model of a claim along with that of an issuer of claims. For example, when a service uses certificates, the underlying claim may be a distinguished name or a subject, while the issuer chains to the root. Likewise, when a service uses Windows integrated authentication and relies on a Windows token (used to identify security principals and security groups), the underlying claim is the username or group and the issuer is the domain. Following up from the previous section on Federation, a service may believe a claim presented by an identity only if it trusts the issuer of the claim. What differentiates a true claims-based approach from other approaches for managing authentication and authorization is that this notion of the claim is called out explicitly in a first-class manner along with the trust relationship between the issuer and the service (usually called the relying party).

For service-oriented architectures, claims enable a loosely coupled model that factors out authentication and authorization logic out of the service. Claims enable services to be loosely coupled to identity and access control.

If you are familiar with the Inversion Of Control pattern, one can think about claims as enabling a similar inversion of control, with the service not having to deal with the logic that supports identity-related capabilities. Instead of the service directly trying to verify and validate the user and their rights and privileges, it is presented with one or more claims issued by a trusted issuer that essentially takes care of all of the work of determining the identity of the user and their rights, including the roles that they belong to and the groups to which they belong.

Aspects of Implementation

Designing Claims

It is useful to start by thinking about claims in the same way that one thinks about attributes in an instance of Active Directory or LDAP or some other central repository. While there is variability based on the size and the culture of the organization, a key constraint is that the schemas for such central repositories are not particularly volatile and there is often a justifiable resistance to extending the schema for these central repositories. It may not be easy, nor may it even be necessary to extend the Active Directory or LDAP schema to incorporate all of the attributes that you believe to be necessary to be issued.

The rule of thumb when designing claims and their constituent attributes is to use attributes that are shared and relevant across a number of services. If an attribute is pertinent to a very small number of services, or perhaps just one service, then it most likely is not a good candidate to be part of a claim.

Whilst claims can comprise almost any meaningful set of attributes, in the real world there are usually some very common claims that are often issued – such as first name, last name, e-mail ID, organization, groups and/or roles, and so on.

Implementing the Security Token Service (STS)

Active Directory Federation Services (ADFS) v2 is an STS that supports WS-Trust, WS-Federation, and Security Assertion Markup Language (SAML) protocols. Windows Server 2008 Enterprise Edition R2 enables the ability to use ADFS v2 as the issuer.

ADFS v2 enables Active Directory Domain Services to be an identity provider (an issuer of identity tokens). It provides the logic to authenticate users using more than one approach, and each instance of an ADFS v2 issuer can be customized to authenticate users with Kerberos, with forms authentication, or with certificates.

An instance of ADFS v2 can be configured to accept a security token from an issuer in another realm as proof of authentication. This enables the federation of identities as we discussed earlier and enables single sign-on across multiple organizations and parties.

Realizing Claims-Based Identity

Realizing claims-based identity requires a series of three steps.

Step 1 - Add logic to the service to understand and to use claims.

(The service needs to know how to verify and validate a claim that it receives.) The WIF provides a common programming model for claims that can be used by both WCF and ASP.NET applications. WIF adds a property that is named Identity.Claims, as shown Example 13.1, which enables the service to identify the claims that were issued, the issuer of the claims, the resource that the claim is associated with, and a string representation of the URI that specifies the right associated with the claim.

Step 2 - Configure the service to trust the issuer.

By default, the recommended, and the most secure approach is to use ADFS v2 as the issuer of tokens. If you have Windows Server 2008 Enterprise Edition R2, you have the ability to use ADFS v2 as the issuer, as we have seen earlier. This will also be the easiest approach for most organizations.

Services and applications trust the issuer to authenticate users and issue claims about their identities. Now that we have a service that understands claims, and we have an issuer of claims, it is necessary to setup a one-way trust relationship between the service or application and the issuer of the claims. The service will need to trust the issuer but not the other way around.

There are several important things to know about an issuer in order to establish trust with it:

  • What claims does the issuer offer?
  • What key should the application use to validate signatures on the issued tokens?
  • What URL must users access in order to request a token from the issuer?

But, how does the service get this information? This information is provided by federation metadata in the form of an XML document that is made available by the issuer. This contains a list of claims the issuer offers, the URL where end users can get a token etc. The federation metadata also includes the issuer’s certificate which provides the service with the appropriate public key to verify incoming tokens. WIF provides a tool called FedUtil.exe that generates this federation metadata for an issuer and automatically configures the relying service(s) based on this metadata.

Step 3 - Configure the issuer to know about the service.

Issuers may only provide claims to authorized services and applications. The issuer needs to have some pre-requisite information about the service or application before it can issue it any tokens:

  • What URI identifies this application?
  • Of the claims that the issuer offers, which ones does this application require and which are optional?
  • Should the issuer encrypt the tokens? If so, what key should it use?
  • What URL does the application expose in order to receive tokens?

There is no one size fits all model with respect to issuing claims to the relying services. Different services might and often will require different sets of claims. One application might need to know the user’s roles while another might only need the last name, and a third might require both last and first names along with the user’s roles, and a fourth might require the last name along with the organization name.

Therefore, how does the issuer obtain this information about the service or application? Again, the WIF tool FedUtil.exe can be used to generate the federation metadata document for the service or application, which is then consumed by the issuer.

Access Control in the Cloud

Windows AppFabric Access Control is a cloud-based security and access control management service that leverages federated, claims-based identities, declarative rules model, and abstracts the complexities in cross-domain authorization and interoperability. Access Control provides the default security layer for Service Bus, but it can also be used to protect any service implementation (on-premise or cloud-based).

Access Control is the cloud-based service that manages the trust relationships, credentials and identities, roles and privileges, and acts as a secure token service to issue claims, and handle claims transformations to enable the use of claims-based identity in enforcing secured access to services. It represents the claims-based access control as-a-service.

This model isn’t significantly unlike earlier paragraphs where we also discussed claims-based service authorizations. The only difference is with Access Control, we have an STS that is already integrated into the Service Bus and can be leveraged seamlessly to support cloud-based service authorizations using federated identities without needing the application clients to implement any part of it.

When a service consumer attempts to connect to a service endpoint on Service Bus that is protected by the Access Control service, Service Bus will require a security token that is issued by Access Control in order to authorize access. This same mechanism is enforced on the service provider as well when a service implementation attempts to attach to and listen on a rendezvous address on Service Bus.

Specifically, service providers need to obtain a token issued by Access Control, which contains a claim stating the listen privilege on the requested service. Service consumers on the other hand, need to obtain a token which contains the send claim. Application clients can obtain these tokens from Access Control by supplying credentials that have been granted permissions to access the targeted service endpoints.

Access Control supports several different types of credentials including shared secrets (simple ID and password, X.509 certificates), Simple Web Tokens (SWT), and SAML tokens.

The programming model supported via the WCF-based AppFabric SDK abstracts the complexities in working with various identity frameworks and interacting with the service implementations. The provided WCF relay bindings transparently handle the credentials exchange, token acquisition, and token submission for establishing access to the service endpoint. Applications without access to the AppFabric SDK can leverage the REST-based API’s when interacting with Access Control.


Because services can impose the need for trust boundaries, services within that boundary typically do not trust external services. For service-oriented solutions comprised of service compositions, claims enable a loosely coupled model that factors out authentication and authorization logic out of the service; enabling services to be loosely coupled to identity and access control.