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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.