Organizations interact with one another. They do so a lot. In fact, many organizations exist solely for the purpose of interacting with other organizations. Only particular types of organizations, such as retailers, schools, hospitals, social service agencies, and some government departments, focus on dealing with individuals. Among those organizations, a recent trend has been to reduce their activity to the ownership of their brand, relying on other organizations for manufacturing, logistics, and customer service (Means and Schneider 2000, 1-18). That trend is evident even in government departments outsourcing their activities to private enterprises.

Yet, despite the fact that their processes involve other organizations, the automation of those processes has mostly been kept stubbornly internal (Daly 2000). Organizations tend to design their automation to suit their own requirements, and make only the most rudimentary accommodation for their automated systems working together with those of other organizations.

This problem is especially evident in how information about the users of systems is managed. If the users of the systems of one organization are to be able to use them to access the systems of another organization, some information about those users must be shared for use in authorizing access to the other organization’s facilities. However, not only is information about users seldom organized for access by multiple organizations, but it is also often not properly organized within any single organization. It is very typical for individual systems to be designed to have their own store of information about their users, so as people join or leave an organization, their information has to be added to, or removed from, each system’s repository of user data.

As long ago as 1988, the organization that is now known as the International Telecommunication Union, and the International Organization for Standardization, released a standard for directory services called X.500. In the mid-1990s, the Internet Engineering Task Force began to publish a slimmer version of X.500 exclusively designed for TCP/IP environments, which is called the Lightweight Directory Access Protocol, or LDAP. The directory services defined by those standards are meant to serve as the central repository for every asset and user in an organization, and also provide a language and an application programming interface for querying that repository.

Microsoft Active Directory, which was initially released as part of Microsoft Windows 2000 Server, was Microsoft’s LDAP-compliant directory service offering. In accordance with its corporate strategy at the time, Microsoft made Active Directory not only LDAP-compliant, but COM-compliant as well.

However, the adoption of directory services like Microsoft Active Directory tends to have been limited to managing access to network resources: to computer desktops, shared folders, printers, and electronic mail. It seldom extends to managing access to software applications, yet less to particular features of those applications or to the items of information they manage.

So anyone designing a software application today can be certain only of these articles of uncertainty:

Consequently, to secure an application today, one would like to have a technology by which access can be readily expanded to include a wider community of legitimate users with diverse ways of identifying themselves. One would also like to have flexibility in how one determines the privileges to which users of the application are entitled. XSI is intended to be just such a technology: a flexible and easily customizable way of controlling access to the resources of a software application.

XSI consists of the set of classes in the System.Security.Authorization namespace of the System.Security.Authorization assembly. That assembly is another of the constituent assemblies of the Windows Communication Foundation, others being the System.ServiceModel and System.Runtime.Serialization assemblies discussed in the previous chapters.

XSI provides a way of controlling access to resources based on claims. To understand how it works, consider this scenario. A man walks into a bar, places his driver’s license and a small sum of money on the bar, and asks the bartender for a beer. The bartender looks at the driver’s license, takes the money, and serves the man a beer.

In this scenario, the bar represents a service. The serving of beer is an operation. The beer is a protected resource. To access it, a person must be of legal drinking age, and must pay a sum of money for it.

The driver’s license and the money both represent claim sets. A claim set is a number of claims provided by the same issuer. In the case of the driver’s license, the issuer is a government department that licenses drivers, and in the case of the money, the issuer is a country’s central bank. However, those issuers are themselves present merely as sets of claims: as logos, signatures, and images on the driver’s license and the money.

Claims consist of a type, a right, and a value. One of the claims in the set of claims represented by the driver’s license is the driver’s date of birth. The type of that claim is date of birth, and the value of that claim is the driver’s birth date. The right that a claim confers on the bearer specifies what the bearer can do with the claim’s value. In the case of the claim of the driver’s date of birth, the right is simply possession. The driver possesses that date of birth but cannot, for example, alter it.

In examining the driver’s license and the money, the bartender translates the claim about the bearer’s date of birth provided by the driver’s license into a claim about the bearer’s age. The bartender also translates the value of each of the proffered items of money on the bar into a claim about the total sum of money being offered. The rules by which the bartender performs these translations from an input claim set to an output claim set constitute the bartender’s authorization policy. The input claim set of an authorization policy is referred to as the evaluation context, and the output claim set is referred to as the authorization context. A set of authorization policies constitute an authorization domain.

In taking the money and serving the beer, the bartender compares the claim about the age of the person asking for a beer to the minimum drinking age, and compares the total sum of money being offered to the price of the requested beer. In that process, the bartender is comparing the authorization context claim set yielded by the authorization policy, to the access requirements for the operation of serving a beer. It so happened that the authorization context claim set of the age of the man asking for the beer, and the total sum of money being offered, satisfied the access requirements for the operation, so the bartender served the man a beer.

To summarize, in XSI, access to an operation on a protected resource is authorized based on claims. Claims have a type, a right, and a value. A claim set is a number of claims provided by the same issuer. The issuer of a claim set is itself a claim set. Authorization based on claims is accomplished in two steps. First, an authorization policy is executed, which takes an evaluation context claim set as input and translates that into an authorization context claim set that it outputs. Then the claims in the authorization context claim set are compared to the access requirements of the operation, and, depending on the outcome of that comparison, access to the operation is denied or granted.

How does this claims-based approach to authorization compare to role-based authorization, which is a fairly common approach to controlling what users can do with software applications? A definition of role-based authorization would be helpful in answering that question.

“Role-based authorization is a mechanism that uses roles to assign users suitable rights for performing system tasks and permissions for accessing resources” (Tulloch 2003, 281). A role is a “symbolic category that collects together users who share the same levels of security privileges” (Tulloch 2003, 281).

Role-based authorization requires first identifying the user, then ascertaining the roles to which the user is assigned, and finally comparing those roles to the roles that are authorized to access a resource. Thus, in the role-based authorization system provided by Microsoft .NET role-based security, for example, the most important element is the principal object, which incorporates a user’s identity and any roles to which the user belongs (.NET Framework Class Library 2006; Freeman and Jones 2003, 249).

By contrast, if one recalls what the bartender did in deciding whether to serve a beer to the man requesting one in the previous scenario, it is noteworthy that identifying the man was not important. Certainly, the proffered driver’s license could also be used to establish the man’s identity, because driver’s licenses do typically make claims about the bearer’s identity, but those claims were not important to the bartender; the bartender was only interested in the license’s claim about the date of birth of the bearer. If the man proceeded to rob the bartender, then no doubt identifying him would become important.

In general, claims-based authorization subsumes role-based authorization. To be precise, roles membership is determined based on identity, identity is just one sort of right to the value of a claim, the right of using the value of the claim to identify oneself. A birth date is not a value of a claim that one has the right to use to identify oneself, because many people share the same birth date, whereas a photographic portrait is a value of a claim that one has the right to use identify oneself. Also, a role is just one type of claim.

How does the claims-based approach to authorization provided by XSI compare to controlling the use of resources with access control lists (ACLs), an approach that is common in administering access to network resources? Once again, having a definition of ACLs would be useful in answering the question.

“ACLs are composed of a series of Access Control Entries (ACEs) that specify which operations [a user or group] can perform on [a resource]” (Tulloch 2003, 7). An ACE consists of a security identifier (SID) identifying a user or group, and a set of access rights defining which operations the user or group is allowed or not allowed to perform on the resource (Tulloch 2003, 7).

ACLs “are used on Microsoft Windows platforms to control access to securable [resources] such as files, processes, services, shares, [and] printers” (Tulloch 2003, 7). Specifically, “[w]hen a user account is created on a Microsoft Windows platform, it is assigned a [SID] that uniquely identifies the account to the operating system” (Tulloch 2003, 7). When the user logs on using that account, an access token is created that contains the SID for that account and the SIDs of the groups to which the account belongs. That token “is then copied to all processes and threads owned by the account” (Tulloch 2003, 7). When the user tries to access a resource secured using an ACL, the SIDs in the token are compared with the SIDs in each ACE of the ACL, until a match is found, and access is either granted or denied (Tulloch 2003, 7).

Once again, claims-based authorization subsumes access control lists as a special case. The credentials by which a user logs on to an operating system, and the SIDs contained in the access token, are both claim sets. The process by which the operating system exchanges the credentials by which the user logs on for the SIDs in the access token that it issues is simply one case of the execution of an authorization policy. Comparing the SIDs in an access token with the SIDs in an ACL is merely an instance of comparing the claims in an authorization context claim set to the access requirements of whatever operation the user wants to perform on the resource secured by the ACL.

However, the more general model provided by XSI works far better than ACLs to accommodate the requirements of authorizing access to a distributed system. There are three reasons.

First, access tokens were never designed to be exchanged across platforms. Claims, by contrast, can be readily expressed in standard, interoperable formats like the one defined by the Security Assertion Markup Language (SAML).

Second, access tokens are issued by operating systems. Claims, however, can be issued by any source.

Third, and most important, the SIDs in access tokens and ACLs are generally useful only within the scope of the operating system issuing the access tokens. If that operating system is a domain controller, the utility of its SIDs will extend as far as the domain does. In contrast, a claim can be meaningful wherever the issuer of the claim is trusted.

However, despite these advantages of claims-based authorization over role-based authorization and access control lists, one should not necessarily eschew role-based authorization and access control lists in favor of claims-based authorization. The use of role-based authorization and access control lists is supported by a vast number of powerful tools. Many such tools are built into Microsoft Windows and their use is customary among network administrators. Support for claims-based authorization is mostly limited to XSI.

So instead of seeing claims-based authorization as a superior alternative to role-based authorization and access control lists, a wiser approach would be to use them together, leveraging their respective strengths where it is most appropriate to do so. Claims-based authorization is especially effective for controlling access to resources across platforms and between organizations. Therefore, in cases in which the users of one organization need to access resources managed by the systems of another organization, have them exchange their access tokens for claims that the other organization can use to decide whether to grant the users access.

How exactly might such a solution be implemented? Well, the Web Services Trust Language (WS-Trust) is a standard language for requesting and issuing claim sets. A system that issues claim sets in accordance with that language is called a security token service (STS) (Gudgin and Nadalin 2005, 7; Cabrera and Kurt 2005, 24-27). An organization whose users need to access the facilities of another organization’s systems could provide their users with an STS from which they could request claim sets that the other organization’s systems would understand. That STS would take the claims constituted by the SIDs in the users’ access tokens and apply an authorization policy that would yield claims with types, rights, and values agreed on with the other organization. That other organization would provide a second STS to accept those claims and apply an authorization policy of its own to yield claims that the other systems within that organization could then use to decide whether to grant a user access to their resources. This solution is depicted in Figure 4.1. The approach has several important virtues.

Figure 4.1. Cross-organization claims-based authorization.

First, trust relationships are minimized and the management of them is centralized. Specifically, the services with resources to protect need to trust the claims from only a single issuer, namely, their own organization’s STS. That STS can be configured to trust claims issued by any number of other organizations’ STSs. Configuring an STS to trust claims issued by another organization’s STS is simply a matter of giving it access to the other organization’s public key.

Second, the claims that one organization makes about its users attempting to access another organization’s services are also hidden from the services by the authorization policy of the STS they trust. That STS applies the authorization policy to translate the claims made by the other organizations into claims that are familiar to the services. That process of translating the diverse sorts of claims that various organizations might make into the sorts of claims that are familiar to a suite of services is commonly referred to as claims normalization.

Third, the administration of access to services is truly federated. Federation is the formation of a unity in which the participants retain control over their internal affairs (Oxford Dictionary of Current English 2001), thereby minimizing the cost of maintaining the unity. In this case, the addition or removal of users and the elevation or reduction in users’ privileges by the system administrators in one organization will determine their rights to access the services of the other organization, without the system administrators of that other organization needing to be involved. This benefit will be vividly demonstrated in the following exercise.

The exercise begins with a Windows Communication Foundation solution in which access to an Intranet resource is controlled using role-based authorization. That solution will show how the securing of Windows Communication Foundation applications simply leverages existing, familiar facilities of Microsoft Windows and Microsoft .NET, saving system administrators from having to learn new concepts and tools and saving software developers from having to learn new concepts and class libraries.

The exercise then proceeds to show how, with XSI, the same resource can be accessed from the same client deployed in a separate, federated organization, with the access being authorized based on claims. What should be impressive is that neither the code of the client nor the code of the service managing the resource will need to be altered to accomplish a fundamental change in how access to the resource is controlled. That should serve as yet another eloquent demonstration of the power of the software factory template for software communications that the Windows Communication Foundation provides, allowing one to fundamentally alter the behavior of an application by making some changes to a model while leaving its code intact.

This first step will demonstrate a Windows Communication Foundation solution in which access to an Intranet resource is controlled using role-based authorization. The role-based authorization is accomplished using .NET Role-Based Security, the ASP.NET 2.0 AuthorizationStoreRoleProvider and the Windows Server 2003 Authorization Manager.

Readers using Windows XP Service Pack 2 can install the Windows Server 2003 Authorization Manager onto their systems by installing the Windows Server 2003 Service Pack 1 Administration Tools Pack. That can be obtained by searching for “Windows Server 2003 SP1 Administration Tools Pack” from the Microsoft Downloads Center.

Follow these instructions to get started:

The next few steps will explain why the coal was accessible but the diamond was not. Begin by following these instructions to open the Windows Server 2003 Authorization Manager user interface:

Evidently, access to resources managed by the Windows Communication Foundation service is being controlled based on the roles to which the user of the client application is assigned within the Windows Server 2003 Authorization Manager authorization store, C:WCFHandsOnSecurityAuthorizationStore.xml. The next few steps will reveal how that is possible:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

         <!-- Application Settings -->
       <appSettings>
              <add key="BaseAddress" value="http://localhost:8000/Woodgrove"/>
       </appSettings>

             <!-- Service Configuration -->
       <system.serviceModel>
           <services>
               <service type="Service.ResourceAccessServiceType"
                           behaviorConfiguration="ServiceBehavior">
                    <endpoint
                           address="ResourceAccessService"
                           binding="wsHttpBinding"
                           contract="Service.IResourceAccessContract"/>
               </service>
           </services>
           <behaviors>
                <behavior name="ServiceBehavior"
                returnUnknownExceptionsAsFaults="true">
                    <serviceAuthorization
                          principalPermissionMode="UseAspNetRoles"  />
                </behavior>
          </behaviors>
      </system.serviceModel>

         <!-- Role Provider Configuration -->
      <system.web>
           <roleManager defaultProvider="AuthorizationStoreRoleProvider"
                           enabled="true"
                           cacheRolesInCookie="true"
                           cookieName=".ASPROLES"
                           cookieTimeout="30"
                           cookiePath="/"
                           cookieRequireSSL="false"
                           cookieSlidingExpiration="true"
                           cookieProtection="All"  >
           <providers>
                  <clear />
                  <add
                       name="AuthorizationStoreRoleProvider"
                       type="System.Web.Security.AuthorizationStoreRoleProvider"
                       connectionStringName="AuthorizationServices"
                       applicationName="RoleProvider" />
           </providers>
       </roleManager>
   </system.web>
         <!-- Connection Strings -->
   <connectionStrings>
            <add
                   name="AuthorizationServices"
connectionString="msxml://C:WCFHandsOnSecurityAuthorizationStore.xml" />
    </connectionStrings>
</configuration>

The binding for the Windows Communication Foundation service that has the resources is the WSHttpBinding. By default, that binding uses the Windows access tokens of the users of client applications to identify those users to the service.

Behaviors were introduced in the preceding chapter. Here the ServiceAuthorization behavior is configured with UseAspNetRoles for its principal permission mode. That configuration specifies that .NET Role-Based Security PrincipalPermission attributes will be evaluated based on output from an ASP.NET 2.0 Role Provider, taking the Windows access token of the users of client applications as input.

The ASP.NET Role Provider is configured lower down in the App.config file. The configuration of the role provider is such that it uses Authorization Manager to determine the roles of users, via the AuthorizationStoreRoleProvider, and the particular authorization store that is being used by Authorization Manager for that purpose is the store C:WCFHandsOnSecurityAuthorizationStore.xml.

So access to the resources of the Windows Communication Foundation service is being controlled by Role-Based Authorization using .NET Role-Based Security and an ASP.NET 2.0 Role Provider. This way of authorizing access to the service’s resources has several benefits.

First, the Windows Communication Foundation is simply configured to delegate authorization to other technologies, to .NET Role-Based Security, an ASP.NET 2.0 Role Provider, and the Windows Server 2003 Authorization Manager. Consequently, the use of the Windows Communication Foundation is not imposing any requirement on software developers or network administrators to learn or adopt new technologies for authorization. Instead, existing technologies that should already be familiar to them are being used.

Second, access to the resources of the service can be administered using the Windows Server 2003 Authorization Manager’s user interface. That user interface, which is very easy for system administrators to use, is built into Windows Server 2003, saving one from having to build a user interface for administering authorization. More information about the Windows Server 2003 Authorization Manager is provided in Dave McPherson’s article “Role-Based Access Control for Multi-tier Applications Using Authorization Manager” (2005).

Third, the selection of where the authorization information for the service is stored, and how it is administered, is controlled through the configuration of the ASP.NET 2.0 Role Provider. The particular Windows Server 2003 Authorization Manager authorization store being used is specified by the connection string so that it can be altered without changing any code. More important, the fact that a Windows Server 2003 Authorization Manager authorization store is being used at all is determined by the selection of the AuthorizationStoreRoleProvider. A different role provider that used a different kind of store for authorization information could be selected in the configuration file, thereby completely altering how access to the application is administered, but, again, without altering any code whatsoever.

using System;
using System.Collections.Generic;
using System.Configuration;
using System.IO;
using System.Security.Authorization;
using System.ServiceModel;
using System.Web;
using System.Web.Security;

namespace Service
{
    public class AccessChecker : OperationRequirement
    {

        private Dictionary<string, string[]> accessRequirements = null;

        public AccessChecker()
        {
            this.accessRequirements = new Dictionary<string, string[]>();

            OperationRequirementsConfigurationSection
                operationRequirementsConfigurationSection
                = ConfigurationManager.GetSection("operationRequirements")
                as OperationRequirementsConfigurationSection;

            OperationRequirementsCollection requirements =
                operationRequirementsConfigurationSection.OperationRequirements;
            List<string> roles = null;
            foreach (OperationElement operationElement in requirements)
            {
                roles = new List"string"(operationElement.Roles.Count);
                foreach (RoleElement roleElement in operationElement.Roles)
                {
                    roles.Add(roleElement.Name);
                }

                this.accessRequirements.Add(
                    operationElement.Identifier,
                    roles.ToArray());
            }

        }

        public override bool AccessCheck(OperationContext operationContext)
        {
            string header =
                operationContext.RequestContext.RequestMessage.Headers.Action;
            string[] requiredRoles = null;
            if (!(this.accessRequirements.TryGetValue(header, out requiredRoles)))
            {
                return false;
            }

            string userName =
OperationContext.Current.ServiceSecurityContext.WindowsIdentity.Name;
            foreach (string requiredRole in requiredRoles)
      {
         if (Roles.Provider.IsUserInRole(userName,requiredRole))
         {
             return true;
         }
      }
      return false;
    }
  }
}

<endpoint address="ResourceAccessService"
  binding="wsFederationBinding"
  bindingConfiguration="TrustWoodgroveSecurityTokenService"
  contract="Service.IResourceAccessContract,Service" >
</endpoint>

<bindings>
    <wsFederationBinding>
    <binding name=”TrustWoodgroveSecurityTokenService”>
      <security mode=”Message”>
        <message>
          <issuerMetadata
            address=”http://localhost:8002/Woodgrove/mex”/>
          </message>
       </security>
    </binding>
    </wsFederationBinding>
  </bindings>

ClaimTypes.Role

The Extensible Security Infrastructure of the Windows Communication Foundation provides a flexible and easily customizable way of controlling access to the resources of a software application. It allows for access to resources to be controlled based on claims. Claims-based authorization subsumes both role-based authorization and authorization using access control lists.

The power of the Extensible Security Infrastructure was demonstrated by an exercise in which access to an intranet service controlled using role-based authorization was extended to permit controlled claims-based access by the users of another organization. That was accomplished by adding security token services built using the Extensible Security Infrastructure to the solution to serve as a foundation for federated identity. In the process, no changes had to be made to the code of either the client or the service, which is an eloquent demonstration of the power that the Windows Communication Foundation can bring to bear on complex business scenarios.