Digital Identity for .NET Applications: A Technology Overview

David Chappell

Chappell & Associates

August 2007

Updated October 2007

Summary: This overview provides a broad introduction to digital identity for .NET architects and developers. After describing a few fundamental concepts, it walks through the major Windows identity technologies and how they can be applied. The goal is to help anyone who works in the .NET world understand and make better decisions about digital identity in their applications. (33 printed pages)

Contents

Understanding Digital Identity in Applications

Identity Within a Forest

Identity Between Forests and Other Identity Scopes

Identity for Internet Applications

Addressing Other Identity Challenges

Conclusion

Understanding Digital Identity in Applications

Working with identity is a critical part of what most .NET application developers do. Whether an application will be accessed within just one company, shared across different organizations, or made available on the Internet, identity has an enormous impact on how an application behaves. Who is allowed to use this application? Does the application behave differently for different users? What data can each user access, and what kind of access is allowed? Whether an application is built by using ASP.NET, Microsoft Windows Communication Foundation (WCF), or some other technology, identity affects its design and behavior in important ways.

Identity in the physical world is expressed in a variety of forms: driver’s licenses, passports, and more. For applications, however, identity typically boils down to a set of bits that are transmitted across the wire, and then used by software. Commonly known as digital identity, this concrete expression of identity is what .NET applications typically work with.

This overview provides a broad introduction to digital identity for .NET architects and developers. After describing a few fundamental concepts, it then walks through the major Windows identity technologies and how they can be applied. Along the way, this description also looks at some important changes that are occurring in how applications work with digital identity. The goal is to help anyone who works in the .NET world understand and make better decisions about digital identity in their applications.

Representing Digital Identity: Tokens

What is digital identity? The clearest way to think about it is as a set of information about some subject. This subject is most often a person, but it might also be an application, a computer, or something else. When it’s transmitted on the network, an identity is represented by some kind of token (also known as a security token). A token is just a set of bytes that expresses information about an identity. As shown in the following figure, this information consists of one or more claims, each of which contains some information about the subject to which this token applies.

Figure 1

The claims in a token commonly contain information such as the name of the user who presents it. They can also contain all sorts of other information; claims aren’t limited to—and don’t even have to include—a subject’s name. And, as the word “claims” suggests, an application that receives a token needn’t blindly accept the information that it contains. Instead, a received token is usually validated in some way before an application uses any claims that it contains.

Tokens come in many different formats. For today’s .NET applications, however, three kinds of tokens are most important. They are the following:

• User name/password token—This very simple token contains only two claims: the name of some subject and that subject’s password.
• Kerberos ticket—More complex than a user name/password token, a ticket includes a subject’s name, the name of the subject’s Windows domain, and other information. Kerberos tickets that are issued by Active Directory also include an extension that contains security identifiers (SIDs) that identify the subject and the groups to which this subject belongs.
• SAML token—The Security Assertion Markup Language (SAML) is an XML-based language that is owned by the OASIS multivendor standards group. Unlike the other token types that are described here, a SAML token doesn’t have a fixed set of claims defined for it. Instead, this kind of token can contain any claims that its creator chooses.

Other kinds of tokens are also used, such as X.509 certificates, and so this list isn’t exhaustive. Still, it’s fair to say that the three listed tokens are today’s most widely used choices for .NET applications.

Sometimes, a token is handled by Windows, with the information that it contains made available to an application through standard objects. This model can work well with fixed-format tokens that always contain the same claims, such as a Kerberos ticket. Newer token formats, however—such as SAML tokens—can contain different claims at different times. Instead of letting the system shield it from what’s in a token, an application can specify the information that it needs, and then examine each token that it receives—processing whatever claims that token contains. As described later, application-oriented identity technologies are increasingly using flexible token formats, such as SAML (for some very good reasons). Given this fact, software developers should expect to focus more and more on this style of application; they’re what the future holds.

Where Tokens Come From: Identity Providers and Token Sources

Every digital identity is created by some identity provider. An identity provider is an authority that makes claims about a person or some other subject. Identity providers typically express those claims in tokens, usually relying on some kind of token source to actually issue tokens. These tokens can then be used to represent identity within some identity scope—for example, some set of systems and applications in which those tokens are accepted.

Here are some examples of identity providers and the token sources that they use:

• If you have an account on your company network, the company is the identity provider. If your firm relies on Windows domains, the token source is provided by Active Directory, which issues tokens as needed. The identity scope in which these tokens can be used typically consists of one or more connected Windows domains within your company.
• If you have an account with Windows Live ID, this Microsoft service is the identity provider. The token source is embedded within the Windows Live ID server, and the scope in which its tokens can be used includes all of the Microsoft Web sites that accept Windows Live ID logons.
• Whenever some Web application asks you to create a user name and password for that site, you are actually creating the claims for a user name/password token. Because you’re the authoritative source of this information, you are the identity provider. The token that you create is usable only at that application (unless you use the same user name and password for many sites, of course).

The Big Picture: Tokens, Identity Providers, Token Sources, and Applications

While the details vary, digital identities are commonly acquired and used in much the same way. The following figure shows the main components in this process:

Figure 2

To begin, the user’s client software acquires a token that represents this user’s identity from some identity provider’s token source (step 1). Next, the client software (which might be a Web browser, a WCF client, or something else) sends the token to the application (step 2). The token might be sent via HTTP, included as part of a SOAP message, or transmitted in some other way. After it has been received, the claims that this token contains are extracted. Some Windows component might do this, or the application itself might use an appropriate application programming interface (API) to examine the token and access the information that it needs (step 3).

As soon as the claims are available, they can be used by Windows, the application, or both. The most common uses of claims include the following:

• Authenticating the user—This means verifying that the claims that describe this user come from an identity provider that the receiver is willing to trust in making decisions. In some cases, this identity provider might be held accountable for ensuring that the user is a specific physical person. In other cases, however, the bar can be much lower. Perhaps all that’s required is recognizing the same user on subsequent accesses, for example, instead of knowing who that user really is.
• Making an authorization decision—Such as deciding whether this user is allowed to access specific information. This can be done in several different ways. The user’s digital identity might be checked against an access-control list (ACL), for example, or the user’s group memberships might be used to allow access based on roles to which those groups correspond. With extensible tokens, such as those defined by using SAML, it’s also possible for the token to carry claims that themselves grant access rights.
• Learning about this user—For example, an application might use information that is carried in the token, such as a user’s name, to look up personalization data about that user. With extensible-token formats, such as SAML, information about the user can also be carried directly in the token, instead of looked up somewhere else.

Domain-Based vs. Claims-Based Applications

As might be obvious by now, the ability to include arbitrary information in a token changes how those tokens can be used. Because of this fact, there’s also a change coming in how applications work with digital identity. This transformation can be thought of as the move from domain-based applications to claims-based applications.

A domain-based application accepts only a single token format with a fixed set of claims. One common example is a Windows application that accepts only Kerberos tickets. This kind of application is easy to create, and it works well inside a single Windows domain. The problem is that this simplistic approach to digital identity is no longer sufficient for many applications. What if this application must also be made accessible from the Internet, for example? This might well require accepting some other form of token, such as a user name/password, and so requires more work by a developer. Similarly, think about an application that only accepts user name/password tokens. Letting users within a Windows domain access this application by using Kerberos tickets might also require significant effort.

A better solution would be to allow a more general approach to working with digital identity. Instead of accepting only a fixed-format token, why not allow applications to work more generally with tokens and the claims that they contain? This is exactly what’s done by a claims-based application. Unlike a domain-based application, a claims-based application can potentially accept multiple token formats with varying sets of claims. The token formats and claim sets that this application accepts are determined by the application itself.

In the simplest case, a claims-based application might accept just one kind of token and require a specific set of claims; that is, it might behave just like a domain-based application, which can be thought of as a subset of claims-based applications. In a more realistic situation, a claims-based application might accept a single kind of token, such as a SAML token, require that a specific set of claims be contained in that token, and yet still be able to use other claims if they appear. In fact, an important aspect of claims-based applications is the increasing use of SAML tokens. While there are scenarios for which this standard format isn’t the right solution, relying on SAML tokens makes interoperability easier in many cases.

Claims-based applications offer a number of benefits. One of the most obvious is that a claims-based application needn’t be locked into a single set of identity information—a single group of claims—expressed in a single token format. This allows it to be used in more diverse environments, such as with clients on the Internet and in an internal Windows domain. Claims-based applications can also more easily accept identities that are defined in other identity scopes—something that’s commonly referred to as federated identity.

Identity Technologies for .NET Applications

Applications that work effectively with digital identity must solve a number of problems. Because of this fact, Microsoft provides several different technologies that address different aspects of this broad challenge. They include the following:

• Active Directory (AD) Domain Services—Provides a full-featured directory service for Windows environments, including a token source for Kerberos tickets. Originally called just Active Directory, this technology is renamed as Active Directory Domain Services in Microsoft Windows Server 2008. This overview uses the new name.
• Active Directory Federation Services (ADFS)—Provides explicit support for claims-based applications, including a token source for SAML tokens. ADFS also allows connecting different identity scopes, which gives Web-browser users single sign-on across them. ADFS is a standard component of Windows Server 2003 R2 and Windows Server 2008.
• Windows CardSpace—Provides an identity selector that lets Windows users work with any kind of token from any identity provider. CardSpace also includes its own identity provider for SAML tokens, which lets users send these more secure tokens, instead of user name/password tokens—thus, reducing the risk of phishing. Windows CardSpace is part of the Microsoft .NET Framework, and so it’s a standard component of Windows today.
• Active Directory (AD) Lightweight Directory Services—Provides a subset of the directory services that are offered by AD Domain Services. Originally known as Active Directory Application Mode (ADAM), this technology also acquires a new name in Windows Server 2008. Like AD Domain Services and ADFS, AD Lightweight Directory Services is a standard part of Windows.
• Identity Life-Cycle Manager (ILM) 2007—Synchronizes identity information (and more) between different identity stores, including AD Domain Services, Microsoft Exchange, Novell eDirectory, IBM mainframes, and others. This allows automating user-account creation, granting of permissions, and other aspects of what’s known as provisioning. The product also includes services for certificate management. Unlike most of the other technologies that are described here, ILM is a separately licensed product.
• Windows Authorization Manager—Provides a standard runtime and tools for applications to use role-based access control—a useful approach to making authorization decisions. Targeted at middle-tier applications, such as those built by using ASP.NET and WCF, Authorization Manager is a standard Windows component.
• Active Directory Rights-Management Services (RMS)—Allows creating and using documents with controlled access rights. Originally known as Windows Rights-Management Services, this technology also acquires a new name in Windows Server 2008. The creator of a document can specify what rights each user has, such as reading the document, printing it, or saving it. An RMS-enabled application then enforces these rights, making sure that every user who accesses that document has only the rights that are granted by its creator. Like Identity Life-Cycle Manager, RMS is a separately licensed product, instead of a standard part of Windows.

This overview looks at each of these technologies—introducing the problems that it addresses, describing the basics of how it works, and outlining how the technology can be used. The goal is to give a big-picture view of Microsoft’s identity technologies for .NET applications.

Identity Within a Forest

If its creators know that an application will always be accessed only by clients inside the same trusted Windows environment, life is simple. For situations like these, a purely domain-based application is fine. The application can rely solely on AD Domain Services to create Kerberos tickets that contain a basic set of claims. It can use those tickets and the information that they carry to represent the identities of its users.

Still, can an application’s creators really know that all of its users will come from a single trusted Windows environment? In many (maybe even most) cases, the answer is no. Accordingly, it’s also possible to create a claims-based application that can work both within a single Windows environment and across different identity scopes. Doing this depends on ADFS and the SAML tokens that it creates. This section looks at the technologies for both approaches.

Active Directory Domain Services

AD Domain Services is the foundation of identity in a Windows environment. Understanding how applications use it—and the tokens that it provides—requires knowing the basics of this widely used technology. This section begins with a short overview of AD Domain Services, and then looks at how applications can use it.

Describing Active Directory Domain Services

All but the smallest organizations can benefit from deploying a directory service. While many directory products are in use, the popularity of Windows has made AD Domain Services today’s most common choice. The following figure illustrates some of the main concepts of this widely used technology:

Figure 3

As the figure shows, the machines in a Windows environment are typically organized into a domain. Two or more domains can be grouped into a forest, with identities that are defined in one domain usable in any other domain in that forest. Whether or not it’s part of a larger forest, a domain must contain one or more Windows server machines acting as domain controllers. Every domain controller runs an instance of AD Domain Services; each one has a complete copy of the directory data for this domain. AD Domain Services uses multimaster replication, so that a change that is made to any copy of the data that it contains is eventually reflected in all copies. A domain also typically contains one or more member servers—which act as file servers, run applications, or perform other functions—along with some number of client machines.

The data that AD Domain Services contains is organized into a hierarchy of objects. Each object contains attributes that describe a person, machine, or something else. As the figure shows, intermediate objects in the hierarchy are commonly defined as organizational units (OUs). In the example that is shown here, the OUs that are immediately below the root represent this organization’s manufacturing and sales departments. Below these OUs are other OUs that contain the users and computers in each department. Each of these leaf objects, in turn, is identified by a common name (CN). Each object in the hierarchy has a unique identifier that is called a distinguished name. This name is formed by concatenating the name of the domain itself with the names of each OU in the path down to the leaf, and then adding the common name of the leaf object.

OUs are important for more than just naming. Instead of requiring every administrator to have complete power over all directory data, AD Domain Services allows administrative rights to be delegated based on OUs. In the example shown previously, for instance, one person might have administrative rights for all of the people and machines that are in the manufacturing OU, while another has administrative rights for the people and machines that are in the sales OU. OUs can also be associated with group policy objects, allowing an administrator to define a set of policies that will apply to the people and machines that are in that OU.

The kinds of objects and attributes that can be stored in an AD Domain Services database, along with the allowed relationships among those objects and attributes, are defined by the domain’s schema. For example, the standard AD Domain Services schema defines a user object, which contains the user’s name and other information, a computer object, an OU object, and many more. All domains in a forest must have the same schema, which means that a change that is made to this schema in any domain will be reflected in all of them. To help find things more quickly, AD Domain Services provides a global catalog that spans all of the domains in a forest.

Clients access AD Domain Services by using the Lightweight Directory Access Protocol (LDAP). Applications that are built on the .NET Framework can issue LDAP requests by using the System.DirectoryServices namespace. This set of .NET types provides a quite general approach to accessing directory services. For access that is specific to AD Domain Services, applications can instead use the System.DirectoryServices.ActiveDirectory namespace.

How Applications Use Active Directory Domain Services

Because AD Domain Services implements Kerberos, the default token in a Windows environment is a Kerberos ticket. To use this default, an ASP.NET application specifies Windows Integrated Authentication, while a WCF application uses an appropriate binding, such as NetTcpBinding. In either case, the following figure illustrates how a Windows application with clients in the same domain might use a Kerberos ticket and AD Domain Services. (It’s worth reiterating that although this simple picture shows a single Windows domain, all domains in the same forest effectively compose a single identity scope. Accordingly, the process that is shown in the figure works with only small variations across domain boundaries in a forest.)

Figure 4

When a user accesses the application, the user’s client software (such as Microsoft Internet Explorer or a WCF client) first causes a request to be sent to AD Domain Services, asking for a Kerberos ticket. Assuming that the client correctly proves its identity (a step not shown here), the AD Domain Services token source—officially known as a Kerberos key distribution center, or KDC—creates this ticket and returns it to the requesting system (step 1). This token is then passed on to the application’s system (step 2). Windows examines the ticket, extracting the user’s identity and other claims. With this information, Windows can authenticate the user, proving that the user really is who the user claims to be (step 3).

In some cases, this is all that’s required. The user’s identity and any groups to which the user belongs are extracted from the ticket and made available to the application. If the user wants to read a file on this system, for example, the application could issue the read request using the user’s identity. Windows will decide whether to grant or deny this access by checking the user’s identity and group memberships against the file’s ACL.

This kind of simple ACL-based authorization decision, however, often isn’t enough; more information about the user than just what’s contained in the Kerberos ticket might be required. Suppose, for example, that this application wants to grant or deny access to a user based on the user’s job title. This information is contained in the user’s AD Domain Services user object. As the preceding figure shows, the application can access this object by using the user’s name to look up the user’s job title in AD Domain Services (step 4). By using the System.DirectoryServices namespace that was mentioned earlier, the application can issue an LDAP query to AD Domain Services, requesting this information. As soon as it knows the user’s title, the application can decide whether that user is allowed to do whatever said user is requesting.

Active Directory Federation Services

If an application can get the identity information that it needs from the claims in a Kerberos ticket, life is simple. But what if the application needs more? One solution, as just described, is for the application to use one or more of the claims in the ticket to look up this extra information in AD Domain Services.

But why make applications do this? Why not include the extra information as claims in the token itself? This could certainly make life simpler for developers. More importantly, using an extensible-token type would let that token include all sorts of claims, even claims that weren’t tied to this particular forest. Doing this means creating a claims-based application, and it makes the most sense to use a token other than a Kerberos ticket.

SAML tokens can address this problem. Because they’re much more extensible than Kerberos tickets, these tokens allow conveying pretty much anything as a claim. For example, a SAML token can be used to represent a digital identity within a Windows forest, much like a Kerberos ticket. Yet it can also be used between forests, and even between a Windows forest and a non-Windows environment. In all of these cases, using SAML tokens with .NET applications today means using Active Directory Federation Services.

Describing Active Directory Federation Services

As the word “federation” suggests, ADFS can be used to convey digital identities across different identity scopes—a topic that is described in the next section. Yet ADFS can also be used within a single Windows forest; and, so, this simpler case is the place to start. The current version, ADFS 1.0, supports only browser clients—a restriction that’s scheduled to change in the technology’s next release. Because this overview describes the current world, however, the description here assumes an ASP.NET application running on Windows Server 2003 R2.

Figure 5

Suppose that a user attempts to access an ASP.NET application within the same Windows domain, as shown in the preceding figure. (As in the Kerberos example that was described earlier, the process is much the same across Windows domains in the same forest.) Like all applications running in an ADFS world, this application relies on an ADFS agent on its machine. This agent requires clients to present SAML tokens, not Kerberos tickets, to authenticate themselves. As soon as the agent notices that this initial request doesn’t carry a SAML token, it redirects the browser to an ADFS server (step 1). The browser then contacts the ADFS server’s token source—authenticating itself with a Kerberos ticket and requesting this SAML token (step 2). Assuming that the authentication succeeds, this token source creates, digitally signs, and returns a SAML token for the application (step 3).

As the figure suggests, this SAML token contains claims that are specific to the application that the user is trying to access. For example, if this application requires the user’s job title, as in the earlier example, that title can be extracted from AD Domain Services, and then inserted directly by the ADFS server into the SAML token that it creates. The browser now repeats its original attempt to access the application—this time, providing the required SAML token (step 4). The ADFS agent on the application’s system verifies the token’s signature, and the application can then use the claims in the token to make an authorization decision or in other ways (step 5).

Because the client is a Web browser, all of the exchanges that are shown here are accomplished via HTTPS; none of the SOAP-based WS-* protocols is used. Also, all of these exchanges are (in this case, at least) transparent to the user. Using ADFS does require action by the Active Directory administrators at this organization, however, and it might or might not be transparent to the developers of the application. What this means for those developers is described next.

How Applications Use Active Directory Federation Services

The simplest way for an application to adapt to the ADFS environment is to ignore ADFS entirely. If an ASP.NET application is configured as an NT token application, it can work in exactly the same way as an application running without ADFS. The ADFS agent on the application’s system will silently transform the information in the SAML token that it receives into the standard Windows format, just as if it had received a Kerberos ticket. While using this option means that the application can’t take advantage of any additional information in the SAML token, it does let existing ASP.NET (or even plain old ASP) applications work unchanged with ADFS. An ADFS administrator will have some work to do, as each of these applications must have an entry configured for it. Still, existing applications that use this option can continue to work as usual.

If an application’s creator knows that ADFS will be deployed, however, the application’s creator can instead create what ADFS calls a claims-aware application. In this case, the application uses the System.Web.Security.SingleSignOn.Authorization namespace to access the claims in the SAML token directly. Exactly what those claims look like is determined by the application developer, who works with an ADFS administrator to define how those claims should be populated with data from AD Domain Services.

Don’t be misled by this simple example. In fact, a claims-based application can use the information in a token’s claims in many different ways. The following are a few examples:

• A claim can grant the right to do something, such as access particular information or invoke specific methods. Instead of requiring the application to make an access-control decision based on the user’s identity, job title, or something else, it could instead make this decision based on the presence or absence of a specific claim in the user’s token.
• A claim can constrain the right to do something. For example, a claim could contain a user’s purchasing limit—letting the application know the maximum amount that this user can spend.
• A claim can convey personalization information, such as the user’s display name. This can allow an application to present a friendlier, more usable interface.
• A claim can convey role membership. Instead of the typical approach of mapping a user’s group memberships into roles, and then making an access-control decision, roles could be defined independently of group memberships. These roles can then be passed directly to an application as claims.

Claims-based applications that use ADFS offer a significantly more general approach to working with identity information than do domain-based applications that rely on Kerberos tickets. ADFS also addresses the problem of cross-scope identity—federation—as described in the next section. Still, thinking of this technology as focused solely on federation is misleading. Instead, ADFS provides generalized support for creating claims-based applications using SAML tokens.

Identity Between Forests and Other Identity Scopes

Everything that has been described so far assumes that an application and all of its clients are inside the same identity scope—in other words, the same Windows forest. But what happens when a user wants to access an application in another forest or in an identity scope that was created with a technology other than AD Domain Services? How can an identity from one scope be used in another?

The answer is identity federation. Simply put, federation allows applications in one identity scope to use identities from an identity provider in another scope. Providing this cross-scope access is important whenever users from one organization need to access a resource, such as a Web application, that is provided by another organization.

Suppose, for example, that your company needs to give its employees access to a Windows SharePoint Services site at a partner company, or perhaps let them access a retirement savings application that is provided by a partner financial-services firm. One approach would be for the partner organization to create a local account for every user in your company. While this solution would work, it’s got plenty of drawbacks. One of the biggest is that users aren’t likely to be happy with it. Along with logging on to their own identity scope, they’ll also need to log on separately to applications in each partner—perhaps, using a different user name and password. Another problem is expense: Administrators in the partner organization are now required to maintain accounts for both their own users and those in your company. And keeping those accounts synchronized will be painful. How is the account of a fired employee in your firm removed from all of the connected partners?

Federation offers a simpler and cheaper approach. Instead of requiring the partner to create accounts for users in your identity scope, the partner agrees to accept identities that are issued by your scope’s identity provider. Doing this has a number of benefits, including the following:

• Users get single sign-on to applications across all federated scopes. Users log on only once to their own scope, and then can access applications in this scope and in every federated scope without being prompted again for logon information. Users can even access an application running in a federated scope from someplace outside of their home scope, such as a hotel room.
• Administrative expenses are reduced, because administrators must create and manage identities for only their own users. Because federation allows their scope to accept identities that are owned by other scopes, there’s no need to maintain local copies of that information.
• No account synchronization is required. When a user leaves the company, for example, the user’s account is deleted in the user’s own scope. Because there are no duplicates of this account in any other scopes, nothing more is required.

The Microsoft technology for identity federation is ADFS. In fact, ADFS works in much the same way across identity scopes as it does within a single Windows forest. Because two distinct scopes are involved, however, a bit more work is required, as the following figure shows:

Figure 6

Although it wasn’t mentioned earlier, the exchanges between a Web browser and the various ADFS components are defined in a multivendor specification that is called WS-Federation. Originally created by Microsoft and IBM, WS-Federation is now implemented in products from Oracle, CA, BMC, and others. Because both the interactions and the token format that ADFS uses are spelled out in this standard, ADFS allows a Windows forest to federate with any identity scope, Windows or otherwise, that also supports WS-Federation.

In the preceding figure, for example, the application is in one identity scope—known as the resource domain—which is using Windows and ADFS. The Web browser is in another scope—known as the account domain—which might or might not be using Windows. Because all of the exchanges are defined by WS-Federation, any technology that implements this specification can be used on either side of the communication.

As before, the process begins when a user attempts to access an application from the user’s browser. The ADFS agent on this application’s machine once again notices that the request doesn’t contain the required SAML token, and so it redirects the browser (step 1). Unlike the single-scope case, however, the browser is now redirected to a resource server—here, implemented by using ADFS. The browser then issues a request to this resource server for a SAML token for the application (step 2). The resource server gives these tokens only to clients that present an appropriate SAML token of their own, however, and so it once again redirects the browser—this time, sending it to an account server in the account domain. The browser then requests this SAML token from the account server’s token source, authenticating itself with a Kerberos ticket (step 3) or perhaps in some other way. Assuming that the authentication succeeds, the account server creates, digitally signs, and returns a SAML token for the resource server (step 4). As before, this token contains claims that are specific to the application that the user is trying to access.

Figure 7

Now that the browser has the SAML token that it needs to prove its identity to the resource server, it once again contacts that server. It presents this new token, and then requests another SAML token for the target application (step 5). The resource server verifies the digital signature on the token that it receives, and then creates and digitally signs a new SAML token for the application and returns it to the browser (step 6). The browser can now repeat its original attempt to access the application—this time, providing the required SAML token (step 7). The ADFS agent on the application’s system verifies the token’s signature; and, as in the earlier example, the application can now use the claims in the token (step 8).

But exactly what claims does the token contain? In the single-domain case that was shown earlier, the answer was simple: The token contained whatever claims the ADFS server inserted into it. With federation, however, there are more options. In this case, the person who installs the application tells the administrator of the resource server what claims this application expects to see in the token. This administrator then tells the administrator of the account server what claims that server should insert into tokens that are created for this application. (Doing this might be a bit challenging, because this administrator likely works for a different organization, but it’s the only way to ensure that the application will get the information that it needs to work correctly.) The account-server administrator causes those claims to be inserted into the SAML token that this server issues. When this token is received by the resource server, as shown in step 6, this server might just copy those claims unchanged into the SAML token that it creates for the application. Alternatively, the resource server can copy only some of the claims into the new token—perhaps, adding others that are available locally—depending on what the application needs. What the application finally receives in the token is the result of this entire process.

To the application, all of this looks just as it did in the single-scope case; it needn’t do anything differently to work with Web browser clients in its own or another scope. As before, an NT token application can behave as if ADFS weren’t present, while a claims-based application can use any extra information that is contained in the SAML token that it receives.

As is probably evident by now, administrators play a central role in making federation possible. For example, because the resource domain is trusting identities that belong to the account domain, it must have some way to verify the SAML tokens that it receives from this domain. Along with the tasks that were already described, administrators do the work that is necessary to establish the necessary trust between the account server and the resource server. To accomplish this, the account server provides its certificate to the resource server in the resource domain. The resource server can then use the public key in this certificate to check the digital signature on each SAML token that it receives, verifying that it really is from this account domain.

One more point worth making is that even with federation, the resource domain might need to create local copies of accounts from the account domain. Any NT token applications that use Windows ACLs must have shadow accounts and/or shadow groups created for them in the resource domain. Without this, there’s no way for the identity in the SAML token to be mapped to a legitimate Windows identity for that domain—a step that’s required to support NT token applications.

Federation provides one more example of the value of claims-based applications. Because there will never be a universal set of claims that all scopes accept, federation requires the ability to transmit and accept diverse claims. Instead of relying on a token that’s bound to a single identity scope, such as a Kerberos ticket, a claims-based application meets this need by using the more general SAML token. And letting this token carry application-specific information is especially useful when the store from which this information comes is in another scope. Directly accessing a store in another organization might be problematic, as organizations aren’t likely to allow this kind of access; thus, carrying the necessary information as claims can be the only pragmatic solution.

As different organizations continue to work more closely together, the need for identity federation grows. In the not-too-distant future, support for federation—and the claims-based approach that it implies—is likely to be required for new applications. In the Windows world, this means that more and more applications will rely on ADFS.

Identity for Internet Applications

When a .NET application and its clients are all in the same forest, a domain-based approach to identity might be sufficient. Even in this case, however, creating a claims-based application can offer advantages. And for applications that will be accessed from other identity scopes, such as another Windows forest, a claims-based approach is required to allow federation. But what about applications that are accessed by users who aren’t associated with any identity scope at all? This is frequently the situation that confronts Internet applications.

By far, the most common choice today for Internet applications is to use user name/password tokens. A better approach is emerging, however, which allows claims-based applications using Windows CardSpace. This section looks at both options.

User Names and Passwords

Whether we like it or not, there are no widely accepted identity providers for the Internet today. No organization has been successful in establishing a service issuing tokens that are accepted by a diverse group of sites. Even Microsoft, which created its Passport service several years ago, wasn’t successful in achieving this. (Now known as Windows Live ID, this service today provides tokens only for accessing Microsoft sites.) In the absence of identity providers, each user effectively becomes their own identity provider creating their own claims: a user name and a password. The following figure illustrates this situation:

Figure 8

As this simple illustration shows, the user provides a user name and password (step 1), which are sent by the client (most likely a Web browser) to the application (step 2). The exact format of the user name/password token can vary on the wire, as different applications do different things; but the claims that are conveyed remain the same. As soon as the token arrives, the application extracts these claims (step 3), and then typically looks up the user in some store (step 4) to authenticate the user. However it’s done, the application can now use this identity to make an authorization decision, look up personalization information, or do anything else that it wants to do.

For ASP.NET applications, a common way to work with user names and passwords is by using a membership provider. The default provider stores this information in Microsoft SQL Server, but other options are possible, such as AD Lightweight Directory Services. Membership providers can be used with ASP.NET’s Forms authentication, which allows an application to display a custom form for collecting a user name and password. Alternatively, for users who have accounts in this Windows domain, the application might issue an LDAP Bind request to Active Directory that contains the user name and password. If the Bind succeeds, this user has a valid account in the domain.

Despite their popularity on the Internet, user name/password tokens aren’t an especially good way to represent identity. (It’s unfortunate that in the most threatening environment—the Internet—we commonly use the least secure kind of token.) Communication between a client and an application, step 2, is commonly encrypted by using Secure Sockets Layer (SSL), so that stealing the token off the wire isn’t much of a threat. But verifying the application at the end of this communication is much more difficult. Phishing sites abound—each trying to fool users into providing a user name/password token for some legitimate site. Because these tokens can easily be reused (they look the same each time), stealing them is valuable.

One solution would be to create identity providers for the Internet. These providers could issue more secure token formats, such as signed SAML tokens, that would be accepted by at least some applications. Another option would be to provide a more secure token format for self-issued identities, one that could effectively replace today’s user name/password tokens. Windows CardSpace, which is described next, aims at both of these targets.

Windows CardSpace

User names and passwords are simple to use. Yet they’re also relatively easy for phishers to steal and reuse. A better solution would be to give users tokens that served the same purpose as user name/password tokens and were just as easy to use, but which wouldn’t have any value if they were stolen. Achieving this is one goal of Windows CardSpace.

Windows CardSpace also has another more ambitious goal: supporting a world with multiple Internet identity providers, each issuing its own preferred kind of token. Applications could then choose which identity providers and which tokens they accept to identify their users. This section gives a brief overview of how Windows CardSpace addresses both of these goals.

Describing Windows CardSpace: The Self-Issued Provider

In all of the technologies that have been described so far, every token source ran on a remote system, such as a domain controller. But why couldn’t a token source also run on each user’s desktop? Because users today act as their own identity providers whenever they send a user name/password token, a local token source could act in this same role. An application could use the tokens that it issued to verify that this was the same user, just as with user name/password tokens. Because they weren’t issued by a provider that the application trusted, the application wouldn’t be able to trust that the user really was who the user claimed to be. Yet this is just like user name/password tokens, where users invent their own names.

Windows CardSpace includes exactly this kind of local token source. Called the self-issued provider, it runs on each client machine. Unlike Active Directory, which implements a token source for all users in a Windows forest, or the original Passport, which attempted to implement a token source (and an identity provider) for all users on the Internet, each Windows CardSpace self-issued provider implements a token source for just one person: the one who is using this machine.

Instead of relying on user name/password tokens, however, the self-issued provider creates signed SAML tokens. Along with carrying other claims, these tokens serve the same purpose as user name/password tokens: They allow users to authenticate themselves to applications. (Because applications rely on tokens to identify their users, they’re sometimes referred to as relying parties.) The following figure shows how the process looks:

Figure 9

Instead of creating a user name and password, the user instead acquires a SAML token from the Windows CardSpace self-issued provider (step 1). This token is then conveyed to the application, which might be built by using ASP.NET or another technology (step 2). The application verifies the token’s signature, and then extracts one or more of its claims (step 3). As usual, the application can use these claims to look up information about the user (step 4) or just use the claims in the tokens directly. To allow applications to identify users uniquely, each token that is issued by the Windows CardSpace self-issued provider contains a field called PrivatePersonalIdentity (PPID). The PPID value can be used as a lookup key to store and retrieve user-specific information. Also, to protect a user’s privacy, a different PPID is sent for each application that a user accesses. (It’s worth noting that today’s standard ASP.NET membership providers don’t accept PPIDs, and so some custom work is required.)

Because the user is in effect signing this SAML token themselves (the key pair is generated locally on the user’s system), it might seem like checking its signature offers very little in the way of authentication. Yet recall what authentication really means: verifying that the claims that describe this user come from an identity provider that the receiver is willing to trust in making decisions. With both a user name/password token and a SAML token that is issued by the Windows CardSpace self-issued provider, the identity provider is the selfsame user. Accordingly, the faith an application places in this provider is exactly the same in both cases. What both kinds of tokens really allow is nothing more than the ability for the application to recognize the same digital identity each time that it is received.

Although the process is much the same as when user name/password tokens are used, there are important differences. One is that, because each SAML token is digitally signed, the application must only verify this signature and extract the PPID to authenticate the user. There’s no need to store user names and passwords to perform authentication (which means that an attack on the application itself can’t reveal this information). Yet the most important difference between a SAML token that is created by the Windows CardSpace self-issued provider and a user name/password token is that the SAML token has no value to a phisher. While a stolen user name/password token can be used to impersonate its user, the SAML tokens that are created by the self-issued provider use cryptographic complexities to make them worthless to a phisher. This makes phishing much less of a threat, because there’s no longer a token for the phisher to steal—and then use—to impersonate this user.

User names and passwords do have one virtue, however: They’re simple for people to use. To make it easier for users to work with a different kind of token, Windows CardSpace represents each identity that it handles with an information card. When users want to log on to an application by using a particular identity, they select a card by using the CardSpace identity selector, as shown in the following figure:

Figure 10

Choosing a particular card causes the selector to request a token for that identity from the self-issued provider. This token is then sent to whatever application the user is accessing. The user can also specify a personal identification number (PIN) that must be entered before a card is used—providing more control. And, as this example shows, the screen allows users to create cards by using the Add a card option.

Providing a more secure alternative to user name/password tokens is a primary goal of Windows CardSpace. Applications that accept its self-issued tokens can reduce the risk of phishing—something that benefits both the application’s owners and its users. Yet CardSpace isn’t limited to working only with its own tokens. In fact, it can work also with tokens that are generated by other token sources from other identity providers. How this works is described next.

Describing Windows CardSpace: Managed Identity Providers

Microsoft’s attempt to create a common identity provider for the Internet—Passport—wasn’t successful. There were a variety of reasons for this, but one of the most obvious is that having just one identity provider isn’t sufficient for the diversity of people and applications on this global network. A more pragmatic approach would be to allow various identity providers, each with its own token source that offered its own kind of token and focused on different areas. For example, a bank might implement an identity provider for its customers, or a regional government might offer one for its residents. Each of these providers could generate tokens in any format—containing whatever claims that it wanted—and each application could choose to accept tokens that were issued by any providers that it trusted.

While Windows CardSpace includes the self-issued provider, it’s also capable of working with tokens that are issued by a managed identity provider. A managed provider is an external identity provider that can create information cards and issue tokens based on those cards. A managed identity provider will typically implement its token source as a security token service (STS). Defined by the WS-Trust specification, an STS supports specific protocols for requesting and returning tokens. The following figure illustrates how managed providers fit into this world:

Figure 11

In this more general situation, the user might get a token from any one of several managed identity providers (step 1), and that token might have any format; it’s not required to use SAML. This token is then sent to the application (step 2), which extracts its claims (step 3) and uses them in any way that it wants. Depending on the contents and format of the token, it might contain a unique key (like the PPID in a self-issued token) that can be used to look up information about a particular user in some store (step 4).

This generality raises another important question: Given the range of possible identity providers, token types, and claims, how can a user know which ones an application will accept? The answer is that the application itself indicates this to Windows CardSpace—either by using HTML or via the approach that is defined by the WS-SecurityPolicy specification. As soon as it knows what identity providers, token types, and claims an application accepts, Windows CardSpace displays its selector screen, but with cards for unacceptable choices dimmed as unavailable. The user then makes a selection from the ones that this application will accept, and Windows CardSpace retrieves a token from the corresponding identity provider’s STS.

Windows CardSpace runs only on Windows, and so it provides a way for Windows users to work with diverse identities. Yet the protocols that it uses and the information cards on which it relies are not tied to Windows. Because of this, a number of organizations have created Windows CardSpace–like solutions for other operating systems, such as Mac OS X and Linux. As these technologies become more widely deployed, we can expect to see more and more applications accept identities that are based on information cards. While all of the components for this world aren’t yet in place (managed identity providers are scarce today, as are applications that accept information-card–based logons), making Windows CardSpace part of Windows will certainly help speed its arrival.

How Applications Use Windows CardSpace

For an ASP.NET application to accept SAML tokens that are issued by the Windows CardSpace self-issued provider, its creator must do a few things. They include the following:

• The application must display a logon screen, indicating that information-card–based logons are accepted. The application can also accept traditional user name/password tokens, and so both options might be available.
• The application must include either an OBJECT tag or specific XHTML syntax in the logon page that it sends to the Web browser. This tells the browser that Windows CardSpace (or perhaps some other identity selector) should participate in the logon process.
• The application must accept an HTTPS POST that contains a token, and then validate that token’s signature. As soon as the token is received, the application must validate its signature and extract its claims.

While ASP.NET applications are most likely to use information cards and Windows CardSpace today, this technology can be used also by WCF applications. The application must be correctly configured, such as by specifying an appropriate binding, and it must validate a received token’s signature before using the claims that it contains. The Windows CardSpace identity-selector screen will appear when the user runs the WCF service, just as it does with a Web browser.

Finally, it’s important to note that support for information cards and Windows CardSpace isn’t limited to Windows applications. While this description is focused on identity for .NET applications, any application that runs on any server operating system is free to accept tokens that are selected via Windows CardSpace or another information-card–based identity selector. Just as ADFS supports the move to claims-based applications within a Windows forest and across identity scopes, Windows CardSpace can help make claims-based applications a reality for the Internet.

Looking Ahead

This overview describes Microsoft’s technologies for digital identity as of mid-2007. While it’s important to understand where these technologies are, it’s also important to have a sense of where they’re going. The best way to get this is by looking at what the near future holds. Nowhere is this more important than with Windows CardSpace.

An important upcoming change is the addition of an STS to Microsoft’s identity offering. The STS will act as a managed provider for Windows CardSpace. Instead of being solely a technology for the Internet, Windows CardSpace can then be used inside enterprises, too. Organizations will be able to issue information cards to their users, and then let those users select the appropriate card for various uses. For example, an employee might choose a high-security identity for authorizing a large payment, and another for more routine tasks. Use of the STS and Windows CardSpace will provide a straightforward way to accomplish this.

Windows Live ID will also provide information cards and implement an STS—letting it act as a managed provider on the Internet. Any application that chooses to do so will be free to accept tokens that are issued by this STS, which means that Windows Live identities can potentially be used with diverse relying parties. Applications are also free to accept tokens from other identity providers, of course (using Windows CardSpace won’t require using Windows Live ID), but adding this ability will give another option for creating and using externally defined identities.

These changes are likely to have a significant impact on how applications are created. Providing a consistent approach to selecting and using tokens within a Windows forest, across forests and other identity scopes, and for applications on the Internet will let application developers take a common approach to identity for all three scenarios. Claims-based applications can become the norm as this more general—and more broadly useful—approach gains wider support.

Addressing Other Identity Challenges

Identity providers, token sources, and the tokens that they create are fundamental aspects of identity today. Important as they are, however, they’re not the only things that developers and architects must think about. How should identity-related information be stored? How can multiple identities that are stored in multiple places be synchronized? And how should authorization be done? This section looks at Microsoft’s technologies for addressing these problems.

Active Directory Lightweight Directory Services

AD Domain Services is a full-featured directory service for Windows environments. There are situations, however, in which this kind of complete solution isn’t what’s needed. For example, developers sometimes want a directory that’s independent from the centrally controlled enterprise directory. Addressing problems like this is the goal of AD Lightweight Directory Services.

Describing Active Directory Lightweight Directory Services

AD Lightweight Directory Services is functionally a subset of AD Domain Services. It provides the same hierarchical database with the same kind of naming, and it uses the same multimaster approach to replication. AD Lightweight Directory Services also allows delegating administrative rights based on OUs, and it can be accessed via LDAP by using either System.DirectoryServices or System.DirectoryServices.ActiveDirectory.

Yet, instead of addressing the broad requirements of Windows domains and forests, AD Lightweight Directory Services is largely focused on working with application-specific data. (The technology’s original name, Active Directory Application Mode, was derived from this fact.) Because of this, AD Lightweight Directory Services differs from AD Domain Services in important ways. Instead of running only on domain controllers, for example, AD Lightweight Directory Services can run on member servers. Instead of requiring the same schema to be used for all directory data in a forest, it’s possible to run multiple instances of AD Lightweight Directory Services—even on the same machine—each with its own schema.

Given its more specialized purpose, AD Lightweight Directory Services also omits the functions of AD Domain Services that aren’t relevant to supporting applications. AD Lightweight Directory Services doesn’t allow organization of domains into forests, for example, and so it doesn’t provide a global catalog. The technology also has no support for group policy, as it’s not meant to be used as a directory service for Windows domains.

AD Lightweight Directory Services also doesn’t implement Kerberos, and so it provides no token source. For applications that accept user name/password tokens, however, this technology can still be used to support authentication by using the approach that was described earlier with AD Domain Services. Instead of connecting to this full-service directory, an ASP.NET application can attempt to establish a connection to an object in AD Lightweight Directory Services—that is, issue an LDAP Bind—passing in a user name and password that it received from a Web browser. As with AD Domain Services, this request will succeed only if an object that has this user name and password exists in the directory—for example, if the application’s user has supplied the correct identity information. AD Lightweight Directory Services also allows creation of a userProxy object for each user who has a user object in AD Domain Services. An attempt to bind to this object will be redirected to that corresponding user object in AD Domain Services. This approach eliminates the need to store sensitive passwords in AD Lightweight Directory Services, while still using it for other application-specific data.

Because they’re built on a common foundation, it shouldn’t be surprising that AD Lightweight Directory Services and AD Domain Services can work together. For example, an application might choose to copy some information about users from AD Domain Services into AD Lightweight Directory Services. To make this easier, AD Lightweight Directory Services provides a tool that is called Adamsync and that can be used to do this—keeping the two directories in sync. (The tool won’t copy data in the other direction, however. As will be described later, AD Domain Services administrators are usually quite touchy about having application-specific data copied into their directory.) Whether it’s populated from AD Domain Services or not, there are often good reasons for applications to use AD Lightweight Directory Services, as the next section explains.

How Applications Use Active Directory Lightweight Directory Services

The most obvious question to ask about AD Lightweight Directory Services is this: Why wouldn’t an application just use AD Domain Services to store its data? Why bother with this simpler version? The truth is that, whenever possible, use of AD Domain Services is usually a better choice. A professional staff deploys and administers this technology, and they also back up the information that it contains.

Unfortunately, use of AD Domain Services to store application-specific data is usually problematic. The most common reason for this is that typical AD Domain Services administrators won’t allow it. They’re not being unreasonable; instead, keeping this central directory service running well is essential to keeping a Windows forest running well. After all, every logon depends on it, as does e-mail and much else. If this core directory service has problems, nobody will be happy. Accordingly, AD Domain Services administrators are very careful about what goes into its database. And, however loudly developers might complain, they don’t usually have much of a voice in setting these policies.

There are also good technical reasons that some kinds of data shouldn’t be kept in AD Domain Services. For example, everything in this directory is replicated to all of the domain controllers in this domain. Paying the performance price that this entails often isn’t justified for data that’s used by only one application. Also, each application typically wants to store its own kind of information, and keeping it in AD Domain Services usually requires extending the directory’s schema. Yet a directory administrator who allows this is opening a Pandora’s box: A plethora of schema extensions is sure to result. Recall that all of the domains in a forest must have the same schema, which means that any changes that an application requests will be reflected throughout an enterprise. Maintaining and managing this diversity can become quite difficult, which is why administrators commonly prohibit schema extensions.

These realities were a primary motivation for the creation of AD Lightweight Directory Services. The ways in which it differs from its big brother—allowing easy schema extension, running on non-domain controllers, and more—address the reasons that AD Domain Services often isn’t a good choice for storing application-specific information. For applications that must store data in a directory instead of a DBMS, AD Lightweight Directory Services will usually be the best option.

Here are some examples of how applications might use AD Lightweight Directory Services:

• Authenticating users for Internet applications—Suppose that an organization deploys an application that can be accessed over the public Internet by both employees and partners. This application might use AD Lightweight Directory Services to authenticate both groups of users. Accounts for partners can be stored directly in AD Lightweight Directory Service objects, while userProxy objects can be created for employees. The application can now authenticate all users in the same way: issue an LDAP Bind request for this user object to AD Lightweight Directory Services. Partner accounts will be found directly in this directory, while employee accounts will be transparently passed to AD Domain Services, as was described earlier.
• Including a directory store with a packaged application—Applications that are written by independent software vendors (ISVs) can sometimes benefit from storing their information in a directory service. For example, an application that can be distributed across various parts of an organization might need a replicated store for its own configuration data. Yet using AD Domain Services for this is problematic, both for the reasons that were described earlier and because there’s no guarantee that every customer will have it installed. Because AD Lightweight Directory Services is a standard part of Windows, an ISV is free to include this technology with its own packaged application. In fact, Microsoft itself does this—including AD Lightweight Directory Services with products such as Exchange Server 2007 and Internet Security and Acceleration (ISA) Server 2006. This is especially useful for firms that offer a suite of products, because it allows using a common identity—and, thus, single sign-on—across the entire suite.
• Providing a common place to store identity information for a range of applications—Especially in organizations that don’t use AD Domain Services, AD Lightweight Directory Services can provide a common place for applications to store identity data. Those applications need not all be running on Windows, because AD Lightweight Directory Services is accessed via standard LDAP.

This last example raises other questions. Does it make sense for applications to rely on a directory service for their identity data? Or is a more realistic solution instead to have each application maintain its own identity data by using a DBMS such as SQL Server? Both approaches have pros and cons, and different situations call for different decisions.

Using AD Lightweight Directory Services allows a common store for identity data—potentially, avoiding duplication of that information. This can make life simpler for organizations that must comply with specific regulatory requirements for handling sensitive data. Because this technology allows delegation of administration rights, it can also help make large amounts of identity information—lots of accounts—more manageable. Another benefit of AD Lightweight Directory Services is its out-of-the-box support for ADFS—allowing the identities that it maintains to be federated.

Yet it’s more common today for Windows applications to use SQL Server to store identity data. Developers aren’t stupid, in the main, so there are good reasons for this. If the identity data with which it works is an important part of the application’s overall data model, storing that data in a relational database with everything else makes sense. The application can issue joins, for example, that use this information—something that’s not possible if identity data is stored only in AD Lightweight Directory Services. Also, most enterprise applications already use a database and ADO.NET. Using these familiar technologies to store identity information is typically easier for application developers than installing AD Lightweight Directory Services (or dealing with the people who control a centralized instance of it), and then learning to use System.DirectoryServices to access it. And, if identity information does have to be federated, it’s possible to write custom code that allows retrieval of data from SQL Server for use as claims with ADFS.

Whether an application uses AD Lightweight Directory Services or SQL Server to store identity data, that information can be synchronized with AD Domain Services (and other identity stores) by using Identity Life-Cycle Manager (ILM) 2007. By making all of this identity information part of a single distributed system, ILM can make life easier for application developers and anybody else who works with identity. How this can be done is described next.

Identity Life-Cycle Manager 2007

Identity information can be stored in a variety of places. A single organization might have some identities in AD Domain Services, others in AD Lightweight Directory Services, and still others in another directory service such as Novell eDirectory. E-mail systems, packaged applications such as SAP, and custom business applications all might also store identity data. Keeping identity information synchronized across these diverse worlds is a challenging problem.

To address this challenge, Microsoft provides Identity Life-Cycle Manager 2007. The successor to Microsoft Identity Integration Server 2003, ILM also includes support for managing certificates. Understanding Microsoft’s approach to identity requires at least a grasp of the basics of ILM.

Describing Identity Life-Cycle Manager 2007

Keeping identity information in sync across different identity stores requires the ability to connect to a diverse group of applications. It also requires defining when and how that synchronization should happen. As the following figure suggests, ILM provides both of these functions:

Figure 12

To connect to diverse systems, ILM includes a set of adapters. Adapters run entirely within ILM itself; no ILM code is installed on other systems. The product includes adapters for various Microsoft products, including AD Domain Services, AD Lightweight Directory Services, SQL Server, and Microsoft Exchange. ILM also includes adapters for products from other vendors, including Novell eDirectory, Lotus Notes, SAP, and more. To access identity information on IBM mainframes, ILM provides an adapter for IBM’s Resource Access Control Facility (RACF) and other mainframe technologies. And, for cases in which the supplied adapters aren’t sufficient, the product includes an Extensible Management Agent for creation of custom adapters.

Adapters let ILM interact with diverse identity stores. To control those interactions, ILM allows its users to create rules and actions. Rules define when something should happen, while actions control exactly what happens. For example, a rule might indicate that, when a new user is added to SAP, that user should be added also to AD Domain Services and Novell eDirectory. To accomplish this, the rule might invoke one or more actions that use the required adapters to interact with the necessary identity stores.

Rules are defined with a graphical tool, but actions are created by a developer; they’re code. This generality means that quite fine-grained behaviors are possible. For instance, ILM can allow things such as giving a user specific rights in three applications, whenever that user joins a particular group in AD Domain Services. In fact, despite the product’s name, rules and actions aren’t required to work solely with identity information; anything that is available via an adapter can be used.

Everything that has been described so far is sometimes referred to as the ILM metadirectory. A second (and, today, quite independent) part of the product is referred to as ILM certificate management. This aspect allows defining, managing, and enforcing policies for certificates. For example, suppose that a user’s request for a certificate requires approval from three managers. Instead of requiring an administrator to get those approvals manually before the certificate is issued, ILM can automate this process. ILM can also load a newly issued certificate onto the user’s smart card.

How Applications Use Identity Life-Cycle Manager 2007

Describing how applications use ILM is simple: For the most part, they don’t. Developers are required to implement the actions that ILM’s rules depend on; but, unlike every other technology that is described in this overview, applications don’t commonly access ILM directly. Still, any application that uses an identity store might well be relying indirectly on ILM to keep its identity information synchronized with what’s in other stores. As described earlier, for instance, an ASP.NET application that stores identity information in its own SQL Server database might rely on ILM to synchronize that information with other identity stores in the organization. Even if an application developer isn’t aware that ILM is being used, this product might still play a fundamental role in ensuring that their application has the right identity information.

Windows Authorization Manager

While applications use identity in many different ways, authorization (also known as access control) is surely among the most important. Making an authorization decision means deciding what a particular subject is allowed to do. Can this user read the file that they’re trying to access? Can they modify this record in that database? Are they able to access a specific part of an application’s functionality?

Windows applications typically have two main options for how to make an authorization decision:

• Impersonation—A thread in the application takes on the identity of—that is, impersonates—the user who wants to access some resource. This thread then attempts access—allowing Windows to check an ACL that determines whether that access is allowed.
• Trusted subsystem—Instead of relying on Windows and ACLs, the application makes its own authorization decisions. This approach can work well with applications that access a DBMS, as it allows efficiencies such as pooling and reusing database connections. The DBMS must trust the application to make these decisions correctly, however, and forfeit the ability to know who its users are—things that not every database administrator is willing to do.

Whatever approach is used, making authorization decisions that are based solely on a subject’s identity is often impractical. There are usually lots of users, and keeping track of which individual has which rights is hard. Instead, it’s common to make these decisions based on the groups to which a user belongs.

A somewhat more general approach is to assign users to roles, and then make authorization decisions that are based on what role a user is in. A role might be mapped to a group—with all members in that group made part of the role—or role membership might be specified in some other way. However it’s done, authorization that relies on roles is known as role-based access control (RBAC). Unlike ACLs, in which permissions are associated with a particular object such as a file, role-based access control associates permissions with particular roles. For example, users in a bank-manager role might be allowed to access data or execute operations that are denied to users in a bank-teller role.

Role-based access control is a natural fit with applications that use the trusted subsystem approach to authorization. In fact, Microsoft has supported role-based access control in COM+ and Enterprise Services applications for some time. Still, a better approach would be to provide a general-purpose technology that Windows applications could use to implement this kind of authorization. This is exactly the goal of Windows Authorization Manager.

Describing Windows Authorization Manager

Sometimes referred to as AzMan, Windows Authorization Manager provides a common technology for Windows applications that must make role-based authorization decisions. Although its exposed interfaces are defined by using the Component Object Model (COM), .NET applications can access AzMan via the COM interop services that are provided by the .NET Framework. The following figure illustrates AzMan’s main components and how they’re used:

Figure 13

Before AzMan can be used, an administrator defines authorization policies by using a Microsoft Management Console (MMC) snap-in (step 1). (This can also be done programmatically via an API that is provided by AzMan.) There are a few options for how these policies can be stored, including AD Domain Services and AD Lightweight Directory Services. Wherever they’re kept, AzMan relies on them to make authorization decisions.

Next, suppose that a user makes a request to access specific information in a DBMS—submitting a token to the application, as usual (step 2). The application logic asks AzMan to make an authorization decision (step 3): Is this user allowed this access? The application passes the claims in the token, such as SIDs from a Kerberos ticket or claims in a SAML token, to AzMan with this request. AzMan uses these claims to determine the roles to which this user belongs (step 4). After it has done this, AzMan consults the relevant policy (step 5)—typically, by using a cached copy, instead of by actually accessing the policy that is stored on disk. It then returns a yes or no decision—approving or denying the access request (step 6). Depending on this result, the application logic then allows or rejects the user’s request for access to this information. Defining authorization policies separately from the application allows those policies to be shared across applications, and it can also provide a common place for administrators to access and work with these policies. Policies are described by using three related concepts:

• Operation—A discrete, low-level function, such as the ability to read data or modify data. Each operation allows making a yes or no decision about whether that function is allowed.
• Task—A set of one or more operations that are focused on doing a particular action. For example, a task such as UpdatePO might contain both a read operation and a write operation. Tasks can also contain other tasks; they can be nested.
• Role—A set of allowed tasks. Each user is associated with one or more application-defined roles. For example, a purchasing application might define roles such as Clerk and Purchasing Manager, while an insurance application’s roles might include Adjuster and Claims Manager. Roles can also contain other roles; that is, they can be nested.

When a developer creates an application, they must define the operations that this application requires, and then associate them with appropriate tasks. They must also determine what the application’s roles are and associate operations with those roles. The developer doesn’t define who is in those roles, however. When the application is installed in a particular organization, a local AzMan administrator can assign users and groups in that organization to the roles that this application defines. This division allows developers to focus on the operations and tasks that must be authorized, while letting administrators control who should be in each role.

It’s also worth noting that roles need not be defined by using the users and groups that are defined within a single organization. While this approach certainly works, it relies on Windows SIDs, and so it assumes that those users and groups are defined in this organization’s forest. In other words, relying on users and groups to define role membership works well only with domain-based applications. To allow federation and the other benefits of claims-based applications, membership in AzMan roles can also be determined based on specific claims that are provided by the user in a token. Doing this allows role memberships to remain independent of user accounts and group memberships that are defined in any particular forest.

How Applications Use Windows Authorization Manager

Using AzMan is relatively straightforward. To ask it to make an authorization decision, for example (as in step 3 in the preceding figure), an application calls AzMan’s AccessCheck method. This method can be invoked before a database access, in front of a call to specific business logic, or anywhere else in an application.

Making authorization decisions is a primary use of identity. For applications that can use role-based access control—a category that includes most ASP.NET and WCF applications—AzMan can help both in implementing these decisions and in managing the policies that guide them.

Active Directory Rights-Management Services

ACLs allow control of which users and groups can access files and other things. Windows Authorization Manager provides a centralized way for an application to determine what users in a particular role can access. Yet, in both cases, as soon as people read information, they can do anything that they want with it: save their own copy, pass it on to people who aren’t authorized to read it, and more. While this is sometimes acceptable, other situations require more control.

Think, for instance, about an Office Excel spreadsheet that contains confidential company information, or an e-mail message whose content shouldn’t be readable by anybody except the people to whom it was sent. Controlling access to information like this requires a different approach. Instead of making access-control information external to the data, why not make it possible for this information to travel with the data itself? This way, any attempt to access data—an Office Excel spreadsheet, an e-mail message, or something else—will be subject to the same access check, no matter where that access takes place. As described next, this is exactly what Active Directory Rights-Management Services (RMS) provides.

Describing Active Directory Rights-Management Services

The easiest way to understand how RMS works is to walk through a simple example. The following figure shows a slightly simplified view of what happens when a user accesses an RMS-protected document:

Figure 14

To begin, the user requests access to an RMS-protected document via some application (step 1). The most widely used RMS-enabled applications today are those of the Microsoft Office suite—including Office Word, Office Excel, Office PowerPoint, and Office Outlook—but pretty much any Windows application can be modified to support RMS. The application passes its user’s request to the local RMS client, which reads the document’s publishing license (step 2). This publishing license contains the policy for this document—listing exactly what access rights each user or group of users has to the information that it contains. It’s similar to an ACL, but with two big differences: A publishing license is part of the document itself, so that it travels with the document; and, unlike an ACL, the license is encrypted, which prevents administrators and anybody else from changing it.

To determine what access rights this user has, the RMS client sends the document’s publishing license along with a token that identifies the user to an RMS server (step 3). As the figure suggests, this license contains a list of the access rights that are available to each user or group of users. The RMS server then decrypts the publishing license (step 4). The key that is required to do this is stored only at this specific server (it’s not kept with the document), and so only this server can extract the contents of the publishing license. To identify the user, the client can supply a Kerberos ticket, a SAML token, or perhaps something else. However the client’s digital identity is expressed, the RMS server matches this identity with the policy in the publishing license. The result is a use license that specifies exactly what access rights this user has to this document. The RMS server sends this new license—encrypted with a user-specific key—back to the RMS client (step 5). The application then grants the user only the level of access the use license allows (step 6).

Because the document itself is encrypted with a key that is contained in the publishing license, it’s not possible for users to access its content in some other way. An RMS-protected document can be decrypted only by an RMS-enabled application, which always relies on an RMS server to create the necessary use license. No matter where the document is copied, even if it’s moved outside of the organization that created it, it always carries its access policy with it—encrypted in its publishing license. Every user’s first access to the document must contact the correct RMS server. (The use license is cached for later accesses, however, which both improves performance and allows offline access to documents.)

In the example that is shown here, the user can read the document; but it’s also possible that no use license is returned (many users will have no rights at all), so that the application might deny access to the document entirely. And don’t be misled by the simple example of access rights that is shown in the figure. In fact, RMS allows specifying a broad range of detailed rights—including things such as controlling the right to print a document, to forward it to others (as with an e-mail message, for example), and more. Rights can also be set to expire after a certain length of time, if desired. And, to make defining rights easier, an organization can create predefined templates that can be applied to documents. For example, a template that allowed documents to be read only by a company’s executive staff might be applied to some financial reports, while another template that grants rights to a broader group of employees might be applied to less sensitive company documents. Also, because every initial access to an RMS-protected document requires contacting the associated RMS server, it’s possible to maintain an audit trail that records who has accessed the document.

It’s worth pointing out how RMS differs from technologies for digital rights management (DRM). DRM is typically focused on licensing content for a specific piece of hardware—controlling things such as whether a particular computer is allowed to play a specific video file. RMS, by contrast, gives individual users rights to access content, such as an Office Word document, regardless of the computer that they’re using.

How Applications Use Active Directory Rights-Management Services

To use RMS, an application can invoke the RMS client to determine access rights for its users. To make this easier, Microsoft provides an RMS SDK for developers. RMS servers also expose SOAP-callable operations—allowing applications to make requests via Web services. For example, an application can use these services to pass an RMS server a publishing license and get a use license in return.

RMS is most commonly used today with document-oriented applications such as Office Word and Office Outlook. This approach to access control can also be used with applications that access other kinds of data, however, such as information that is stored in relational databases. For example, an application that is created by using ASP.NET or WCF might be required to submit a publishing license to get the right to access a connection to a database or to execute a particular stored procedure. It’s also possible to associate publishing licenses with specific records in a database—providing fine-grained access control via RMS.

Conclusion

As the range of topics that are described in this overview illustrates, working with digital identity requires at least some knowledge of several different technologies. In the not-too-distant future, however, the move from domain-based applications to claims-based applications should simplify the lives of .NET developers.

Today, creating an application with users in both a local Windows forest and on the Internet probably requires the use of different kinds of tokens that contain wholly distinct claims: Kerberos tickets in the forest, and user name/passwords on the Internet. As soon as ADFS and Windows CardSpace are widely deployed, that same application can expect the claims it that needs to be delivered in a consistent form (most likely, via SAML tokens), regardless of where its users are. This will help developers create an application without knowing in advance how it will be accessed—in a forest, across federated scopes, on the Internet, or all three—because the way in which it works with identity will be the same in every case.

Handling identity well should be a fundamental part of every enterprise application. Understanding identity technologies is also fundamental, because it’s the only way to make good decisions about an application’s design. Going forward, a solid knowledge of this area will be a bedrock competence for anybody who creates .NET Framework applications.

About the author

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps IT professionals around the world to understand, use, and make better decisions about enterprise software.