http://msdn.microsoft.com/en-us/library/bb833027.aspx

Chapter 6: Identity and Access

This topic has not yet been rated - Rate this topic

"Your identity is your most valuable possession – protect it.

 If anything goes wrong, use your powers."

- Elasti-Girl,

from the film "The Incredibles"

 

Contents

Reader ROI
Acknowledgements
Identity and Access
Trusted Subsystem Design
An Identity Metasystem
Conclusion
SOA Case Study: OTTO
References

Reader ROI

Readers of this chapter will build upon the concepts introduced in previous chapters, specifically focusing on the Identity and Access architectural capability.

Figure 1. Recurring Architectural Capabilities

In this chapter readers will learn about Microsoft's identity and access strategy. We will discuss the laws of identity – a set of guiding principles that are learned from operating real world identity systems. We will also describe an identity metasystem that can lead to safer and more trustworthy Internet computing.

Topics discussed in this Chapter include:

• Terms and concepts associated with Identity and Access
• The Laws of Identity
• Identity federation scenarios
• Trusted Subsystems
• An Identity Metasystem

Acknowledgements

The concepts discussed in this chapter are entirely drawn from earlier efforts in this space. We wish to thank the following individuals for their work in this area: Kim Cameron (The Laws of Identity) and Fred Chong (terms, concepts and identity federation scenarios, and trusted subsystem design).

Identity and Access

Overview

Identity and Access focuses on the management of identities with support for the following aspects:

• Management of multiple roles (identities): An employee may serve different roles within an organization – each of these roles need to be served appropriately based upon context, process and other factors.
• Propagation of identities: Propagating the various identities used by both simple and complex business processes can be a challenge. Identities must be passed between each service involved in the business process in a seamless manner. The identities used by a given process must also be granted appropriate access rights to the resources necessary for the process to complete successfully.
• Cross-Boundary Integration: Business processes can span departments, companies and countries. Disparate cross-department, cross-company collaboration, regardless of resource or employee locations.
• Applying and managing business-rules to identities: Next to the creation and the management of identities, rules are needed that define how these identities should be handled (e.g. caching/time limitation and other issues).
• Delegation of management functions to business units: Identities convey much more information than a simple "Username / Password". The responsibility of identity content, rules and management is evolving into a business function instead of an administrative function for IT. Business units must be able to manage and maintain their identities in an autonomous manner.

Most large organizations have multiple security systems in place. SOA projects need to leverage the organization's existing IT investments, meaning the solution will need to interact with a broad range of security systems. Without comprehensive security integration strategy in place the organization will need to determine security, identity and access requirements on a case by case basis. This leads to increased development and deployment times as well as application-specific security issues. If applications fail to address these issues then the burden for interacting with various security systems falls to the user, resulting in overly complex user experiences, lower productivity and increased risk. Security Integration is generally concerned with five central issues:

• Who are the users?
• How do they prove it?
• What can they access?
• What level of privacy is required?
• How and when are access privileges granted, extended or revoked?

The solution to these issues is to adopt a framework that effectively hides the security details of from new solutions. Once this framework has been established the organization's legacy applications must be adapted to make use of it. Policies for new applications should be adopted to ensure that new solutions will also use the security integration framework.

There are several additional benefits the organization can derive from a standardized security integration framework:

• Workers will no longer be forced to manage multiple sets of logon requests and demands, avoiding lost productivity and potential security vulnerabilities.
• New employees have to wait too long for their accounts to be created.
• Corporate security and privacy policies are inconsistently or ineffectively enforced.

As stated earlier, security integration and identity management are critical topics that must be addressed by any SOA solution. Organizations that adopt a consistent security integration and identity management strategy are:

• More efficient: Organizations can better connect and collaborate with their customers, partners and suppliers.
• More productive: Users can be more productive since delays accessing systems or resources are minimized. Management of user identities is also more productive associated with providing access to needed systems are reduced (e.g. like described, multiple password requests are handled by the applications themselves).
• More efficient from an Operational Costs perspective: A consistent security integration and identity management strategy enables common tasks like password resets to become user-driven self service options, greatly reducing overall help desk call volumes.
• More Secure: Consistent security integration and identity management strategies enable corporate and governmental policies and compliance mandates to be implemented at an enterprise level instead of on a department by department basis.

Now that we've got some familiarity of the benefits an organization can derive from a consistent identity management strategy, let's take a closer look at some of the principles for identity management in a large distributed system. Increasingly organizations are deploying or using solutions that use the Internet. Some of these solutions use the Internet to communicate with trading partners while SaaS-based solutions may be delivered over the Internet.

Trusted Subsystem Design

While decomposing applications into multiple layers facilitates certain design and deployment activities, it also introduces challenges into the development of different facets of application solutions. Of those design issues, recurring ones concern controlling and accounting for access to business data and computing resources exposed by each application tier.

Figure 2. Access control and auditing requirements for multi-tiered applications

In Figure 2 we see a typical distributed system. Systems like this typically raise the following types of concerns:

1. Who can invoke interfaces at Web Service 2?
2. Who can connect to the business database?
3. How should the business data be filtered with respect to privacy and business regulatory policy requirements?
4. How do we audit and keep records of data access?

We will use the scenario illustrated by Figure 2 to explain these design considerations. Figure 2 shows a generic multi-tiered application that is a good representation of the current generation of line-of-business (LOB) applications. In this scenario, a business application initiates an application request through a method in Web Service 1. Web Service 1 is a façade service that in turn calls another method in Web Service 2 to process the user request. The method in Web Service 2 implements internal business logic. Part of the business logic processing requires business data that must be fetched from a backend database. Before responding to the call from Web Service 1, the business logic implementation also writes the business event into an audit log for accounting purposes. The following access control and accounting requirements may arise from this scenario:

How should we control access to computing resources that provide business logic computation services (such as Web Service 2) and the database that provides data management services? Web Service 2 implements important business logic that is critical for enforcing business policies and processes. Enterprises may want to restrict the ability to execute such mission critical code to a subset of identities. Similarly, the database is where the crown jewels of the business reside. The rights to connect to the database should be handed out judiciously.

Who should be allowed to access the data? Data privacy requirements or business policies may limit the business information that can be viewed and manipulated by the business application user. For example, insurance agencies may restrict viewing of customer data to the assigned insurance agent. In this case, the business logic will need to make authorization decisions based on the identity of the application user (e.g. the insurance agent) and the customer data retrieved from the database. This enforcement is sometimes known as data entitlement.

Who has already accessed the data? Regulatory requirements may mandate businesses to keep an audit trail of all data related activities, with regard to who accessed what data and when. In our scenario, the Web service will need to know the identity of the business application users to keep accurate records.

Current Practices

Currently, there are two prevalent models for fulfilling the needs described above:

• Impersonation and Delegation
• Trusted Subsystem

We will describe the two models conceptually and mention how today's implementations of the models are used to solve the access control and auditing issues mentioned above. We will then detail some limitations with the current approaches and then apply a set of trusted subsystem design principles to derive an alternative solution.

Impersonation and Delegation

Delegation is the process of allowing another party to act on behalf of an identity. This process bestows upon a party the rights and privileges of another party to perform a set of tasks. Impersonation can be viewed as the most relaxed form of delegation such that one identity is assigned the complete set of permissions of the impersonated identity. There are two common ways of implementing delegation:

An identity creates a signed statement with a set of permissions that is assigned to the stated party for a specific duration of time, so that the stated party can present the signed statement and act on the identity's behalf.

A trusted third party issues signed statements to stated parties enabling those stated parties to act on another identity's behalf for a certain amount of time.

The first model is easier to implement when the subject delegating the rights is aware of the parties that are performing tasks on its behalf. However, in the current multi-tiered distributed computing environment, this is not the common case. More often than not, an end user is not aware of the services that are interacting to complete the user's requests. In these cases, a more suitable form of delegation is used; a third party authorizes on-behalf-of requests. The Kerberos security protocol is a popular implementation of such a scheme. The Kerberos delegation model does not assume that the end user knows about all the cooperating services beforehand. With Kerberos, the Kerberos Distribution Center (KDC) issues "forwardable" tickets that allow services to act on each user's behalf.

Using the Windows impersonation and Kerberos delegation approach, a service wanting to propagate the caller identity will first make an application request to the Windows operating system to impersonate the user locally. Note that impersonation is considered a highly restricted function and the application process identity must possess the Trusted Computing Base (TCB) privilege to impersonate a user. This right can only be assigned by a system administrator on the local machine. When the application process impersonates a user, everything it does locally is authorized and audited using the impersonated user's identity. This means that an application process may also acquire user privileges that the application process identity would not normally have when not impersonating a user.

Kerberos delegation enables an application process to acquire a Kerberos service ticket on behalf of the impersonated user, and the impersonated user's identity is carried forward in the acquired service ticket. The application process can then invoke the remote service using the acquired Kerberos service ticket. The downstream service being invoked will process the request according to the identity in the Kerberos service ticket. Thus, through the delegation process, the (original) user's identity is propagated to downstream services.

In our previous scenario, using Windows impersonation and Kerberos delegation, it is possible to flow the original user's identity downstream, so that the business logic Web service can perform more granular authorization, such as data-level entitlement, as well as record the impersonated user's identity in the audit trail.

Other than enabling multi-tier applications to make application authorization decisions, using Windows impersonation and Kerberos delegation also enhances the security of the application environment through the following features:

With Windows Kerberos constrained delegation, administrators can further configure delegation policies so that services can be restricted to act on behalf of users for only a given set of services.

The Kerberos protocol allows mutual authentication, which means that services can authenticate each other, thus reducing the risks of interacting with rogue services.

Impersonation and Kerberos delegation are readily available capabilities that are built into the Windows operating systems. This means enterprises that have an Active Directory directory services infrastructure can reuse the same security infrastructure to enable application security.

Despite these benefits, there are also limitations with using the impersonation and delegation model:

Impersonating users at the OS process level can elevate the process privilege, which may have unintended consequences as a result of elevation-of-privilege security attacks.

Kerberos delegation requires the application process to contact the KDC to obtain a service ticket on behalf of the user before accessing and invoking downstream services. For applications that are accessing downstream resources on behalf of a large number of users, this security negotiation with the KDC introduces an extra communication latency which may not be acceptable. The obvious solution to cache such security contexts across multiple requests violates stateless recommendations for high performance services.

Some applications optimize their performance by sharing a pool of pre-created communication channels for connecting and communicating with downstream services. For example, many business logic tier services have a pool of database connections that the services reuse to communicate with the downstream database. To meet security requirements, each of these database connections requires authentication. When impersonation/delegation is used to propagate the security context of the original caller, an authenticated database connection is created for each impersonated user and the connection pooling technique cannot be used to optimize application performance.

Access to services such as the business logic Web service must be secured using the impersonated user's identity. In other words, it is necessary to grant permissions to end users to call mission-critical code. In many cases, this is not an acceptable assumption, from the following perspectives:

• It violates the particular view of defense-in-depth which gradually reduces the number of identities that can access higher value assets. The fortress analogy is quite appropriate here. Layers of defensive walls protect the center core of command and control. Fewer trusted officials of higher ranks are allowed access as we move toward the inner core of the fortress. To abide by this principle means that the ability to invoke inner business logic should be restricted to a small set of application identities. When end users can also invoke these services, the security of these services is also dependent on (and at the mercy of) the efficiency of the end user de-provisioning process.
• Giving end users the ability to invoke business logic services also increases the complexity of managing access control for the service. Instead of only having to manage the access rights of a few application identities, we now have to deal with end user identities instead.

Trusted subsystems

The limitations of the impersonation and delegation model provide the motivation for considering the trusted subsystem model.

By definition, the trusted subsystem model implies that application services are trusted to perform a specific set of application tasks, such as processing customer orders. Frequently, downstream services need to make application authorization decisions, such as approving an order submission before performing the business transaction. To do so, the service must know the identity of the end user submitting the order. While the ability to flow the identity of the end user is an inherent property of the delegation model, it is not so for the trusted subsystem model and special efforts must be made to include this feature.

The notion of "trusted" does not come for free. To support the notion of trust as defined by the model the services must at least be able to:

Authenticate and verify the identity of the upstream or downstream service they are communicating with.

Decide if the identified service is a trusted subsystem for a specific set of application functions, including propagating identity claims.

Protect the integrity of the data being communicated between trusted subsystem and downstream services. Besides application data, application plumbing data, such as the identity claims of the original user, must also be protected so that no man-in-the-middle can modify the identity information that is in transit.

However, many current implementations of alleged "trusted subsystems" do not meet these minimum safeguard requirements. We will substantiate this claim using some observations on how current trusted subsystems are propagating the original user's context.

A common practice today is to propagate the identity of the caller as a custom HTTP or SOAP header. The downstream service looks in the custom HTTP and SOAP header when it needs the original caller's identity. Since the identity propagation often occurs within the organization's network, many application administrators naively assume that it is safe to propagate the data unprotected. In actual fact, many, if not most, application security breaches occur within the organization's internal networks.

Adding transport layer protection, such as using SSL\TLS with client and server authentication, can reduce the security attack surface quite significantly. In Web services environments where Web services endpoints may span multiple transport hops, adding Web service layer security can reduce the chances of man-in-the-middle attacks. This is done by requiring the services to mutually authenticate each other's integrity and protect the custom SOAP header.

We can also potentially build on existing X509 public key infrastructure to help a downstream service decide if an upstream service is a trusted subsystem. For instance, a custom certificate usage OID can be defined for a trusted subsystem so that it is issued certificates that contain the trusted subsystem usage OID. The issued certificate may also contain client and server authentication OID, so that the same certificate can also be used for HTTPS or Web services authentication using the X509Certificate token profile.

Up to this point, the proposed solutions are low hanging fruits that existing trusted subsystem solutions can incorporate to add additional security protection.

Trusted Subsystem Design Goals

In the next section, we will describe an infrastructure design that allows us to meet the trusted subsystem requirements previously stated. In addition, this trusted subsystem design also satisfies an additional set of security attributes for flowing identity claims. The design goals for this system are summarized below.

1. Enable downstream services to authorize service invocations based on application identities instead of end user identities. This requirement helps simplify access management of the service interface.
2. Enable a downstream service to positively identify an upstream caller and determine if the upstream caller is also a subsystem trusted for specific application functions. The design must not assume that all application services are trusted subsystems. Instead, it must use security policy mechanisms to specify and determine the kind of application functions that a service can perform.
3. Enable an upstream service to protect its communication with downstream services so that the data can be guarded against tampering and other attacks.
4. Enable an upstream service to propagate the identity of the original caller to downstream services. The identity context of the original caller is frequently used by application services to authorize business tasks and audit an individual's actions. The design should make this identity data available to the application.
5. Unlike the impersonation and delegation model, the design must not operate under the premise of "acting on behalf" of the original user, therefore changing the identity of the application process or thread. The solution should allow trusted subsystems to function like airline service representatives performing the check-in procedure at ticketing counters for identified travelers. The service representatives are not impersonating or acting on behalf of the travelers. Instead, they are the persons that are authorized to perform check-in procedures for travelers at check-in counters. The trusted subsystem design must not require an application to assume another identity to perform its application function.
6. In certain cases, a downstream service receiving a propagated identity from a trusted subsystem may also need additional evidence to accept the identity and proceed with the application requests. The process requirement here is akin to the U.S. green card application process. In many companies, corporate attorneys assist with initiating and preparing the green card application for foreign employees. After the initial preparation process is completed, the application document prepared by the corporate legal department is sent to the federal immigration office along with other official documents, such as the applicant's passport. The passport is the additional piece of information that the U.S. federal immigration office will use to prove the identity of the applicant. In the same way, downstream services may require additional evidence from a third party other than the trusted subsystem or user to support the identity claims received from trusted subsystems. For this requirement, our design takes into consideration the following specific evidences that may be required:
7. 
   
8. • It must be possible for a downstream service to verify that the owner of the propagated identity claim has been recently authenticated by a trusted third party. This reduces the window of time available for a compromised trusted service to propagate false identity claims.
   • To further reduce the possibilities of false identity propagations, the service must be able to verify from material facts (for example, the original caller's signature) that a specific call originated from the identity previously identified through the set of propagated claims. This requirement builds on the previous one.
9. Decouple the credentials that are used for authentication from the ones that are used to make trusted subsystem claims. This requirement facilitates security policy management. For example, authentication credentials such as X509 certificates usually have a longer lifespan, whereas a service's claim with respect to being a trusted subsystem may have a shorter lifespan that is dependent on the service location in the application environment.

Trusted Subsystem Design

There are two important requirements that must be met in the process of identifying a trusted subsystem:

1. The services that are interacting with each other must know that they are communicating with the intended party.
2. In situations where not all application services are considered as trusted subsystems, there must be a way for a service to further differentiate services that are trusted to propagate identities from those that are not trusted.

In the previous section, we have already described a few ways where services can mutually authenticate each other. It is certainly possible to leverage existing technologies to accomplish mutual authentication, such as using HTTPS with client and server side X509 certificates or the Kerberos protocol.

In addition to these solutions, it is also possible to use emerging Web service-based technology, such as a security token service that provides third-party brokered authentication to a group of Web service-based applications.

Beyond the authentication and SSO services that are provided by such brokered authentication services, we show here how it is possible to extend the infrastructure so that services can also ride on the authentication mechanism to authorize services as trusted subsystems.

Figure 3. A trusted subsystem design

Figure 3 shows a trusted subsystem design that is built on a security token service and provides authentication and SSO service. The underlying security protocols supporting such an infrastructure can be composed by using existing Web services security specifications such as WS-Security, WS-Trust and WS-SecureConversation. This design demonstrates a multi-tiered application scenario where two users, Alice and Bob, are using two instances of Web service applications to access a front-end Web service. The front-end Web service communicates with a downstream Web service to complete the application request.

The next section provides background information detailing how a typical SSO infrastructure for Web services can be expected to function. The information is intended to provide the basic framework which we will extend to implement the trusted subsystem design.

Basic Web service SSO framework

Referring to the scenario shown in Figure 3, Alice and Bob authenticate with the security token service to acquire a session token from the STS as a proof of authentication. Subsequently, Alice and Bob can use their respective session tokens with the STS to request service access tokens to the front-end Web service without having to re-authenticate with their primary credentials (for example, password or certificates). The service access token is used to negotiate session keys and prove knowledge of secrets to establish mutual authentication.

The same SSO infrastructure used by Alice and Bob to authenticate and achieve SSO with the front-end Web service is also used by the Web services to mutually authenticate each other. For example, before the front-end Web service can communicate with the downstream Web service, it is required to authenticate with the STS to acquire an STS session token and a service access token to the downstream Web service. Both Web services then mutually authenticate and set up a secure session with each other. The secure session handshaking protocol can be set up by leveraging Web services protocol building blocks such as WS-secureconversation. This secure session negotiation process only has to be done once during the lifespan of the service access token. When the service access token is no longer valid, it may be renewed and the secure session must be renegotiated. Such an infrastructure proves to be very useful for large categories of distributed applications and services that are deployed in enterprises today. The mutually-authenticated security sessions improve security while minimizing performance overhead, since the initial security negotiation can be amortized over multiple application requests and responses transacted through the Web services.

It is also important to note that the concept of security sessions is orthogonal to the application communication paradigm. At first glance, it may appear that such SSO infrastructure is only useful for distributed applications that communicate synchronously. This is not true. The same infrastructure can also be used to secure distributed applications that service asynchronous long-running transactions.

Trusted subsystem process extensions

Returning to the topic of a trusted subsystem, we now propose an extension to the plain-vanilla SSO infrastructure by introducing the notion of trusted subsystem policies. The exact trusted subsystem policy model and language may take many forms, and it is not the goal of this document to specify or limit the mechanisms that can be used with this infrastructure level design.

In Step 2 of the high level process shown in Figure 3, the STS checks a trusted subsystem policy store to find out if the front-end Web service requesting a service access token to the downstream Web service is a trusted subsystem for the downstream Web service. If it is, the STS includes the trusted subsystem claim in the access token issued to the front-end Web service. The trusted subsystem claim and the rest of the data in the token are signed by the STS so that the downstream Web service can verify the party (STS) authorizing the claim.

When the downstream Web service processes the access token sent by the front-end Web service in Step 3, it verifies the authenticity of the trusted subsystem claim and notes the fact that the front-end Web service is a trusted subsystem. Depending on the specific nature of the claim, the downstream Web service may accept propagated identities in subsequent application requests from the front-end Web service. Note that the downstream Web service may still enforce requirements for additional evidence supporting the propagated identities. We will discuss the enforcement of this requirement later.

Trusted Subsystem Policies

In addition to the issuance, processing, validation, and enforcement of trusted subsystem claims, there is also a management component for manipulating the trusted subsystem policies. Trusted subsystem policies may take many forms. Existing authorization models such as role-based authorization may also be used to specify trusted subsystem policies. The example shown in Figure 4 modeled different services (workflow services and data adapter services) as application resources. Each of the application resource services may permit the upstream service to perform certain actions according to the role that the accessing service is assigned to. For instance, the trusted subsystem role is defined for the workflow and data adapter services so that trusted services that belong to these roles are permitted to propagate identities to the application resource services. We can then assign individual services to their respective trusted subsystem roles defined for these application resource services.

Figure 4. An example of a trusted subsystem policy using role-based representation

When the STS receives a service access token request for a particular downstream service, it checks whether the requesting service belongs to the trusted subsystem role defined for the downstream service. Alternatively, the STS can also check if the requesting service is allowed to propagate identities to the downstream service. If the result of the policy check asserts that the requesting service is a trusted subsystem, the STS inserts the trusted subsystem claim in the issued access token. It is important for the issued token to have scoping elements defined such that the trusted subsystem claim applies only to the particular downstream service that the policy check has approved. There are many ways that the trusted subsystem claim may be transported inside the service access token. For example, if the service access token is a SAML 1.1 token, the trusted subsystem claim could be a SAML Authorization Decision Assertion inside the SAML token:

  <saml:AuthorizationDecisionStatement Decision="Permit"  Resource="http://downstreamservice.multitierwebservice.com">   <saml:Actions Namespace="http://...">   <saml:Action>PropagateIdentities</saml:Action>   </saml:Actions>   <saml:Subject>    <saml:NameIdentifier Name="http://frontendservice.multitierwebservice.com" />   </saml:Subject>  </saml:AuthorizationDecisionStatement>      

In the example provided above, the upstream service identified by the URI http://frontendservice.multitierwebservice.com is a trusted subsystem permitted to propagate identities to the downstream service identified by the URI http://downstreamservice.multitierwebservice.com.

Flowing an Original Caller's Identity Claims

In the previous section, we illustrated how trusted subsystems may be permitted to propagate the original caller's identity claims to downstream services. At the beginning of the paper, we also mentioned the requirement that downstream services may require additional evidences to verify and support the genuineness of the flowed claims. The additional evidences are claims generated by parties other than the immediate upstream trusted subsystem, since different parties may be trusted to assert a limited set of claims. Such capabilities enable the downstream services to assemble additional evidence to securely process the request. For instance, for a downstream service to process a high value financial transaction, such as a $500,000 transfer, there is a need to know that the request in fact has been initiated by the subject identified in the flowed claim. We do not want compromised trusted subsystems to be able to generate such requests under the guise of any user.

In this section, we will show how trusted subsystems can support these requirements by describing the categories of propagated identity tokens.

Categories of flowed tokens

The following types of tokens may be propagated by the trusted subsystem:

1. Trusted subsystem generated identity tokens
2. Third party generated identity tokens
3. User self-signed tokens

The first type of propagated identity tokens is generated and issued by the trusted subsystem flowing the identity claims. This token can be as simple as a WS-security username token without the password element, or as complicated as a custom identity token that contains non-standard claims inserted by the trusted subsystem. In all cases, the trusted subsystem signs the identity token before propagating the generated token to downstream services.

For the next few examples, we use the <OriginalCaller> XML element to contain the propagated identities.

In this specific example, the UsernameToken is used to propagate the context of the original caller.

  <OriginalCaller>   <UsernameToken>    <Username>...</Username>   </UsernameToken>  </OriginalCaller>      

A more complicated example of a custom token generated by a trusted subsystem may look like:

  <OriginalCaller>   <CustomUserContextToken Issuer="http://trustedsubsystem1.multitierwebservices.com">    <Username>...</Username>    <Roles>…</Roles>   </CustomUserContextToken>  </OriginalCaller>      

In addition to the name of the original caller, the issued custom token also contains application roles that the user belongs to. Such information may help downstream services make access decisions.

The second type of propagated token comes from a third party that is trusted to perform a set of specialized functions, such as a security token service that provides authentication and single sign-on services to Web services.

The following example shows a trusted subsystem propagating a signed SAML token issued by an STS that provides single sign-on services:

  <OriginalCaller>   <saml:Assertion AssertionId="SecurityToken-745d68f1-9c63-4216-9fd5-9ebd96fab986"  MajorVersion="1" MinorVersion="1" Issuer="http://sso-sts.multitierwebservices.com"  …>   …    <ds:signature>…</ds:signature>   </saml:Assertion>  </OriginalCaller>      

The third category of propagated tokens is generated and signed by the user that originated the call. The signature in the token enables trusted subsystems and downstream services to verify the asserted claims in the token.

Here is an example of a user self-signed token that can be used to correlate an application request with the original caller:

  <OriginalCaller>   <CallerEvidenceToken>    <Subject>     <X509CertficateToken>…</X509CertificateToken>    </Subject>    <Timestamp>…</Timestamp>    <MessageID>uuid:  5b19a5f5-426c-4cfa-b953-d5dc200e9508</MessageID>    <Signature>…</Signature>   </CallerEvidenceToken>  </OriginalCaller>      

The original caller has attached an X509 certificate so that the subject in the X509 certificate can be identified as the original caller. Within the signed evidence, a timestamp element denotes the time when the evidence is generated and a message identifier is used to identify the chain of application requests initiated by the original caller. The timestamp and message identifier are then signed using the private key associated with the X509 certificate.

It is also possible to identify the subject in the evidence via some other means of tokens. For instance, we can also use a username token (without password) with a signature generated using a derived key from the password and some other random data.

This table summarizes the conditions that may lead one to use one type of token over the other:

Token Type	Usage Conditions
Trusted Subsystem Generated Token	When downstream services trust the trusted subsystem to assert the original caller's identity, without requiring additional evidence from other parties.
Third Party Generated Token	When the downstream services trust the trusted subsystem to assert claims regarding the original caller in conjunction with third party evidence that satisfies an additional set of security requirements. For instance, downstream services may want to know that the originating user was recently authenticated by a trusted third party. In this case, the propagated token could be a SAML token issued by an STS providing SSO service.
User Self-Signed Token	When the trusted subsystem is authorized to perform a set of application functions and when there must be evidence from the original caller that the caller initiated the request.

Table 1. Token type and usage conditions

Identity/credential mapping

With identity/credential mapping, a service takes a given identity, and with or without the help of a third party (such as a single sign-on service), maps the given identity into another related set of credentials. The set of mapped credentials may or may not contain authentication data, such as the logon password. The services then use this set of new credentials to gain access to downstream resources. We consider this to be a special function of the trusted subsystem role, where the goal is to transform an identity to another related identity (could be a change in type or namespace) for the purpose of gaining access to downstream resources that only recognize the transformed identity. It is important to note that the types of propagated identity tokens discussed above do not exclude token types that result from the process of identity or credential mapping.

Benefits of the Design

In view of the application requirements that we have discussed, the new approach described in this document brings about the following benefits:

It considers current application optimization techniques that focus on resource sharing, such as connection pooling, so that an application designer can minimize the tradeoff costs between security and performance. In our model, the trusted subsystem maintains a security session with downstream services. A security context is established for the trusted subsystem that allows the downstream services to exactly authorize and determine the scope of the trust. Subsequently, identity is flowed using one of the three token types mentioned. There is no need for services to establish per-user security context as required by the impersonation/delegation model.

It cleanly separates out the security concepts and goals of "acting-on-behalf-of" versus "authorized-to-perform." Our trusted subsystem solution outlines the requirements and steps that are necessary to design "authorized-to-perform" systems, which is the model needed to secure a large number of the multi-tier applications currently deployed. Applications requiring delegation should continue to use existing protocols such as Kerberos.

Our design addresses the frequent need of downstream systems to know the identity of the original caller by implementing secure propagation of the original caller's identity claims.

Trusted subsystem behavior is managed and driven through policies, allowing for more flexibility in configuring and securing the tiers between applications. The same application service can be configured to be a trusted subsystem when communicating with a CRM service and not a trusted subsystem when communicating with a billing service. Such flexibility encourages reuse of loosely-coupled service components.

The credentials to prove trusted subsystem claims are decoupled from those that are used to authenticate and identify the services. Authentication credentials are typically longer-lived while application service roles may be different depending on how the service is being used within the larger distributed application context. Our design allows more flexibility for changing service capabilities without introducing additional management overhead and the need for revoking and reissuing authentication credentials.

Design principles and infrastructure implementations to facilitate trusted subsystem communications and identity claims propagation are some of the most needed but also most under-investigated areas in application security. The design we discussed is fully in tune with current service-oriented computing paradigm, where explicit service boundaries, loose–coupling, and policy-driven behavior are key design attributes. With our design approach, services do not make any a priori assumptions about whether a service is a trusted service, services are not tightly bound to a specific set of trusted services or trust settings, and the scope of service trust can be adjusted through configurable run time policies.

There are several important security requirements that are fundamental to trusted subsystem designs, which are:

• The ability for services to mutually and positively identify each other.
• The ability for services to determine if whether to trust the identity claims propagated from another service.
• The ability for a service to protect the integrity of application data and identity claims transacted through trusted subsystems.

An Identity Metasystem

For users and businesses alike, the Internet continues to be increasingly valuable. More people are using the web for everyday tasks, from shopping, banking, and paying bills to consuming media and entertainment. E-commerce is growing, with businesses delivering more services and content across the Internet, communicating and collaborating online, and inventing new ways to connect with each other.

But as the value of what people do online has increased, the Internet itself has become more complex, criminalized, and dangerous. Online identity theft, fraud, and privacy concerns are on the rise, stemming from increasingly sophisticated practices such as "phishing". The multiplicity of accounts and passwords users must keep track of and the variety of methods of authenticating to sites result not only in user frustration, known as "password fatigue", but also insecure practices such as reusing the same account names and passwords at many sites.

The root of these problems is that the Internet was designed without a system of digital identity in mind. In efforts to address this deficiency, numerous digital identity systems have been introduced, each with its own strengths and weaknesses. But no one single system meets the needs of every digital identity scenario. And even if it were possible to create one system that did, the reality is that many different identity systems are in use today, with still more being invented. As a result, the current state of digital identity on the Internet is an inconsistent patchwork of ad hoc solutions that burdens people with different user experiences at every web site, renders the system as a whole fragile, and constrains the fuller realization of the promise of e-commerce.

What is the Identity Metasystem?

Given that universal adoption of a single digital identity system or technology is unlikely ever to occur, a successful and widely employed identity solution for the Internet requires a different approach — one with the capability to connect existing and future identity systems into an identity metasystem. This metasystem, or system of systems, would leverage the strengths of its constituent identity systems, provide interoperability between them, and enable creation of a consistent and straightforward user interface to them all. The resulting improvements in cyberspace would benefit everyone, making the Internet a safer place with the potential to boost e-commerce, combat phishing, and solve other digital identity challenges.

In the offline world, people carry multiple forms of identification in their wallets, such as driver's licenses or other government-issued identity cards, credit cards, and affinity cards such as frequent flyer cards. People control which card to use and how much information to reveal in any given situation.

Similarly, the identity metasystem makes it easier for users to stay safe and in control when accessing resources on the Internet. It lets users select from among a portfolio of their digital identities and use them at Internet services of their choice where they are accepted. The metasystem enables identities provided by one identity system technology to be used within systems based on different technologies, provided an intermediary exists that understands both technologies and is willing and trusted to do the needed translations.

It's important to note that the identity metasystem does not compete with or replace the identity systems it connects. Rather, it plays a role analogous to that of the Internet Protocol (IP) in the realm of networking. In the 1970s and early 1980s, before the invention of IP, distributed applications were forced to have direct knowledge of the network link, be it Ethernet, Token Ring, ArcNet, X.25, or Frame Relay. But IP changed the landscape by offering a technology-independent metasystem that insulated applications from the intricacies of individual network technologies, providing seamless interconnectivity and a platform for including not-yet-invented networks (such as 802.11 wireless) into the network metasystem.

In the same way, the goals of the identity metasystem are to connect individual identity systems, allowing seamless interoperation between them, to provide applications with a technology-independent representation of identities, and to provide a better, more consistent user experience with all of them. Far from competing with or replacing the identity systems it connects, the metasystem relies on the individual systems to do its work!

Identities Function in Contexts

The identities held by a person in the offline world can range from the significant, such as birth certificates, passports, and drivers' licenses, to the trivial, such as business cards or frequent coffee buyer's cards. People use their different forms of identification in different contexts where they are accepted.

Identities can be in or out of context. Identities used out of context generally do not bring the desired result. For example, trying to use a coffee card to cross a border is clearly out of context. On the other hand, using a bank card at an ATM, a government-issued ID at a border, a coffee card at a coffee stand, and a Passport Network (formerly .NET Passport) account at MSN Hotmail are all clearly in context.

In some cases, the distinction is less clear. You could conceivably use a government-issued ID at your ATM instead of a bank-issued card, but if this resulted in the government having knowledge of each financial transaction, some people would be uncomfortable. You could use a Social Security Number as a student ID number, but that has significant privacy implications, even facilitating identity theft. And you can use Passport accounts at some non-Microsoft sites, but few sites chose to enable this; even where it was enabled, few users did so because they felt that Microsoft's participation in these interactions was out of context.

Studying the Passport experience and other digital identity initiatives throughout the industry led us to work with a wide range of industry experts to codify a set of principles that we believe are fundamental to a successful, broadly adopted, and enduring digital identity system on the Internet. We call these principles "The Laws of Identity".

The Laws of Identity

The "Laws of Identity" are intended to codify a set of fundamental principles to which any universally adopted, sustainable identity architecture must conform. The Laws were proposed, debated, and refined through a long-running, open, and continuing dialogue on the Internet. Taken together, the Laws define the architecture of the identity metasystem.

They are:

1. User Control and Consent: Identity systems must only reveal information identifying a user with the user's consent.
2. Minimal Disclosure for a Constrained Use: The identity system must disclose the least identifying information possible, as this is the most stable, long-term solution.
3. Justifiable Parties: Identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
4. Directed Identity: A universal identity system must support both "omnidirectional" identifiers for use by public entities and "unidirectional" identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
5. Pluralism of Operators and Technologies: A universal identity solution must utilize and enable the interoperation of multiple identity technologies run by multiple identity providers.
6. Human Integration: Identity systems must define the human user to be a component of the distributed system, integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
7. Consistent Experience Across Contexts: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

To learn more about the Laws of Identity, visit www.identityblog.com.

Roles within the Identity Metasystem

Different parties participate in the metasystem in different ways. The three roles within the metasystem are:

• Identity Providers, which issue digital identities. For example, credit card providers might issue identities enabling payment, businesses might issue identities to their customers, governments might issue identities to citizens, and individuals might use self-issued identities in contexts like signing on to web sites.
• Relying Parties, which require identities. For example, a web site or online service that utilizes identities offered by other parties.
• Subjects, which are the individuals and other entities about whom claims are made. Examples of subjects include end users, companies, and organizations.

In many cases, the participants in the metasystem play more than one role, and often all three.

Components of the Identity Metasystem

To build an identity metasystem, five key components are needed:

1. A way to represent identities using claims.
2. A means for identity providers, relying parties, and subjects to negotiate.
3. An encapsulating protocol to obtain claims and requirements.
4. A means to bridge technology and organizational boundaries using claims transformation.
5. A consistent user experience across multiple contexts, technologies, and operators.

Claims-Based Identities

Digital identities consist of sets of claims made about the subject of the identity, where "claims" are pieces of information about the subject that the issuer asserts are valid. This parallels identities used in the real world. For example, the claims on a driver's license might include the issuing state, the driver's license number, name, address, sex, birth date, organ donor status, signature, and photograph, the types of vehicles the subject is eligible to drive, and restrictions on driving rights. The issuing state asserts that these claims are valid. The claims on a credit card might include the issuer's identity, the subject's name, the account number, the expiration date, the validation code, and a signature. The card issuer asserts that these claims are valid. The claims on a self-issued identity, where the identity provider and subject are one and the same entity, might include the subject's name, address, telephone number, and e-mail address, or perhaps just the knowledge of a secret. For self-issued identities, the subject asserts that these claims are valid.

Negotiation

Negotiation enables participants in the metasystem to make agreements needed for them to connect with one another within the metasystem. Negotiation is used to determine mutually acceptable technologies, claims, and requirements. For instance, if one party understands SAML and X.509 claims, and another understands Kerberos and X.509 claims, the parties would negotiate and decide to use X.509 claims with one another. Another type of negotiation determines whether the claims needed by a relying party can be supplied by a particular identity. Both kinds of negotiation are simple matching exercises; they compare what one party can provide with what the other one needs to determine whether there's a fit.

Encapsulating Protocol

The encapsulating protocol provides a technology-neutral way to exchange claims and requirements between subjects, identity providers, and relying parties. The participants determine the content and meaning of what is exchanged, not the metasystem. For example, the encapsulating protocol would allow an application to retrieve SAML-encoded claims without having to understand or implement the SAML protocol.

Claims Transformers

Claims transformers bridge organizational and technical boundaries by translating claims understood in one system into claims understood and trusted by another system, thereby insulating the mass of clients and servers from the intricacies of claim evaluation. Claims transformers may also transform or refine the semantics of claims. For example, a claim asserting "Is an employee" might be transformed into the new claim "OK to purchase book". The claim "Born on March 22, 1960" could be transformed into the claim "Age is over 21 years", which intentionally supplies less information. Claims transformers may also be used to change claim formats. For instance, claims made in formats such as X.509, Kerberos, SAML 1.0, SAML 2.0, SXIP, and others could be transformed into claims expressed using different technologies. Claims transformers provide the interoperability needed today, plus the flexibility required to incorporate new technologies.

Consistent User Experience

Many identity attacks succeed because the user was fooled by something presented on the screen, not because of insecure communication technologies. For example, phishing attacks occur not in the secured channel between web servers and browsers — a channel that might extend thousands of miles — but in the two or three feet between the browser and the human who uses it. The identity metasystem, therefore, seeks to empower users to make informed and reasonable identity decisions by enabling the development of a consistent, comprehensible, and integrated user interface for making those choices.

One key to securing the whole system is presenting an easy-to-learn, predictable user interface that looks and works the same no matter which underlying identity technologies are employed. Another key is making important information obvious — for instance, displaying the identity of the site you're authenticating to in a way that makes spoofing attempts apparent. The user must be informed which items of personal information relying parties are requesting, and for what purposes. This allows users to make informed choices about whether or not to disclose this information. Finally, the user interface provides a means for the user to actively consent to the disclosure, if they agree to the conditions.

Benefits of the Identity Metasystem

Microsoft recognizes that the identity metasystem will only gain widespread adoption if participants filling all roles in the metasystem stand to benefit from their participation. Fortunately, this is the case. Key benefits of the identity metasystem include:

Greater user control and flexibility. Users decide how much information they disclose, to whom, and under what circumstances, thereby enabling them to better protect their privacy. Strong two-way authentication of identity providers and relying parties helps address phishing and other fraud. Identities and accompanying personal information can be securely stored and managed in a variety of ways, including via the online identity provider service of the user's choice, or on the user's PC, or in other devices such as secure USB keychain storage devices, smartcards, PDAs, and mobile phones

Safer, more comprehensible user experience. The identity metasystem enables a predictable, uniform user experience across multiple identity systems. It extends to and integrates the human user, thereby helping to secure the machine-human channel.

Increases the reach of existing identity systems. The identity metasystem does not compete with or replace the identity systems it connects, but rather preserves and builds upon customers' investments in their existing identity solutions. It affords the opportunity to use existing identities, such as corporate-issued identities and identities issued by online businesses, in new contexts where they could not have been previously employed.

Fosters identity system innovation. The identity metasystem should make it easier for newly-developed identity technologies and systems to quickly gain widespread use and adoption. Claims transformers can allow new systems to participate even when most participants don't understand their native claims formats and protocols.

Enables adaptation in the face of attacks. New technologies are needed to stay ahead of criminals who attack existing identity technologies. The metasystem enables new identity technologies to be quickly deployed and utilized within the metasystem as they are needed.

Creates new market opportunities. The identity metasystem enables interoperable, independent implementations of all metasystem components, meaning that the market opportunities are only limited by innovators' imaginations. Some parties will choose to go into the identity provider business. Others will provide certification services for identities. Some will implement server software. Others will implement client software. Device manufacturers and mobile telephone players can host identities on their platforms. New business opportunities are created for identity brokers, where trusted intermediaries transform claims from one system to another. New business opportunities abound.

A benefit we will all share as the identity metasystem becomes widely deployed is a safer, more trustworthy Internet. The metasystem will supply the widely adopted identity solution that the Net so desperately needs.

Participants in the identity metasystem can include anyone or anything that uses, participates in, or relies upon identities in any way, including, but not limited to existing identity systems, corporate identities, government identities, Liberty federations, operating systems, mobile devices, online services, and smartcards. Again, the possibilities are only limited by innovators' imaginations.

An Architecture for the Identity Metasystem: WS-* Web Services

Microsoft has worked for the past several years with industry partners on a composable, end to end architecture for Web Services. The set of specifications that make up this architecture have been named the WS-* Web Services architecture by the industry (see http://msdn.microsoft.com/webservices/). This architecture supports the requirements of the identity metasystem.

The encapsulating protocol used for claims transformation is WS-Trust. Negotiations are conducted using WS-MetadataExchange and WS-SecurityPolicy. These protocols enable building a technology-neutral identity metasystem and form the "backplane" of the identity metasystem. Like other Web services protocols, they also allow new kinds of identities and technologies to be incorporated and utilized as they are developed and adopted by the industry.

To foster the interoperability necessary for broad adoption, the specifications for WS-* are published and are freely available, have been or will be submitted to open standards bodies, and allows implementations to be developed royalty-free.

Deployments of existing identity technologies can be leveraged in the metasystem by implementing support for the three WS-* protocols above. Examples of technologies that could be utilized via the metasystem include LDAP claims schemas, X.509, which is used in Smartcards; Kerberos, which is used in Active Directory and some UNIX environments; and SAML, a standard used in inter-corporate federation scenarios.

Identity Metasystem Architectural Diagram

Figure 5. An Identity Metasystem

This figure depicts sample relationships between a subject, identity providers, and relying parties, showing some of the technologies used by the metasystem and by specific systems utilized through the metasystem.

• The Security Token Server implements the WS-Trust protocol and provides support for claims transformation.
• Relying parties provide statements of requirements, expressed in terms of the WS-SecurityPolicy specification, and made available through the WS-MetadataExchange protocol.
• The Identity Selector implements the consistent user experience. After being invoked by an application, it performs the negotiation between relying party and identity provider(s), displays the identities of "matched" identity providers and relying parties to the subject (e.g. the end user), obtains claims, and releases them to the application under the supervision of the subject.

Implementing the Identity Metasystem

.NET 3.0 includes the following software components for participation in the identity metasystem:

Identity selector: CardSpace is a .NET 3.0 component that provides the consistent user experience required by the identity metasystem. It is specifically hardened against tampering and spoofing to protect the end user's digital identities and maintain end-user control. Each digital identity managed by "InfoCard" is represented by a visual "Information Card" in the client user interface. The user selects identities represented by "InfoCards" to authenticate to participating services.

Simple self-issued identity provider: CardSpace also includes a simple identity provider that enables individual PC users to create and utilize self-issued identities, enabling password-free strong authentication to relying parties. A self-issued identity is one where the user vouches for the information they are providing, much like users do today when registering with a Web site. We are implementing the simple self-issued identity provider to help bootstrap the identity metasystem; we believe self-issued identities will continue to be accepted for certain classes of services. Identities hosted in the simple self-issued identity provider will not include or store sensitive personal information, such as Social Security numbers (or other national ID numbers if these are developed) or credit card numbers. Self-issued identities are not intended to provide the full range of features that a managed identity provider can offer - the market is wide open for companies to provide managed identity solutions to consumers.

Active Directory identity provider: This is a managed identity provider integrated with Active Directory. It includes a full set of policy controls to manage the use of Active Directory identities in the identity metasystem. Active Directory Federation Services, a new Active Directory feature shipping in Windows Server 2003 R2, is the first step to integrating identities in Active Directory with the identity metasystem.

WCF: Windows Communication Foundation web services provide developers a way to rapidly build and deploy distributed applications, including relying party services in the identity metasystem.

The identity metasystem preserves and builds upon customers' investments in their existing identity solutions, including Active Directory and other identity solutions. Microsoft's implementation will be fully interoperable via WS-* protocols with other identity selector implementations, with other relying party implementations, and with other identity provider implementations.

Non-Microsoft applications have the same ability to use CardSpace to manage their identities as Microsoft applications will. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.

What About Passport?

Microsoft's best-known identity effort is almost certainly the Passport Network (formerly .NET Passport). Microsoft has learned a great deal from building one of the largest Internet scale authentication services in the world, and applied these hard-won lessons in developing the Laws of Identity, the identity metasystem, and several of our products.

Passport was originally intended to solve two problems: to be an identity provider for the MSN and Microsoft properties, and to be an identity provider for the Internet. It succeeded at the first, with over 250 million active Passport accounts and over 1 billion authentications per day. As for the second original goal, it became clear to us through continued engagement with partners, consumers, and the industry that in many cases it didn't make sense for Microsoft to play a role in transactions between, for instance, a company and its customers.

Apart from its input to our thinking on the Laws of Identity, it is worth mentioning that operating the Passport service has helped Microsoft gain a deep understanding of the operational and technical challenges that large-scale identity providers face. These experiences have helped us ensure that our identity products meet the needs of large-scale deployments.

The identity metasystem is different from the original version of Passport in several fundamental ways. The metasystem stores no personal information, leaving it up to individual identity providers to decide how and where to store that information. The identity metasystem is not an online identity provider for the Internet; indeed, it provides a means for all identity providers to coexist with and compete with one another, with all having equal standing within the metasystem. Finally, while Microsoft charged services to use the original version of Passport, no one will be charged to participate in the identity metasystem.

The Passport system itself has evolved in response to these experiences as well. It no longer stores personal information other than username/password credentials. Passport is now an authentication system targeted at Microsoft sites and those of close partners – a role that is clearly in context and with which our users and partners are very comfortable. Passport and MSN plan to implement support for the identity metasystem as an online identity provider for MSN and its partners. Passport users will get improved security and ease of use, and MSN Online partners will be able to interoperate with Passport through the identity metasystem.

Conclusion

In this chapter we briefly discussed the benefits of a identity and access strategy. We also discussed a set of design principles for facilitating a trusted subsystem. The chapter closed with a detailed look at the capabilities of an identity metasystem. These capabilities are exposed today in the Microsoft .NET 3.0 Framework.

Many of the problems on the Internet today, from phishing attacks to inconsistent user experiences, stem from the patchwork nature of digital identity solutions that software makers have built in the absence of a unifying and architected system of digital identity. An identity metasystem, as defined by the Laws of Identity, would supply a unifying fabric of digital identity, utilizing existing and future identity systems, providing interoperability between them, and enabling the creation of a consistent and straightforward user interface to them all. Basing our efforts on the Laws of Identity, Microsoft is working with others in the industry to build the identity metasystem using published WS-* protocols that render Microsoft's implementations fully interoperable with those produced by others.

SOA Case Study: OTTO

Since its first mail-order catalog in 1950, OTTO has always sought retail innovation by introducing new distribution methods, customer channels, and shopping experiences. Today, OTTO is the world's number one mail-order company and the number two online retailer.

OTTO decided to build a virtual store for fashion apparel that would transcend traditional e-commerce limitations and foster closer relationships with customers. OTTO also wanted to introduce entirely new e-commerce features, such as community tools and drag-and-drop user controls.

OTTO built the virtual OTTO Store using the Microsoft .NET Framework 3.0. OTTO Store is a smart client that takes advantage of local hardware and software resources for a rich and responsive user experience, but it also integrates deeply with Web resources. OTTO Store uses Windows CardSpace for application authentication functions. Windows CardSpace provides users with an easier and safer shopping experience, saving them the hassle of typing in user names and passwords. OTTO is considering Windows CardSpace for use across its e-commerce operations, including future iterations of its leading retail Web site.

The entire Case Study is available online at http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=200504

See other SOA case studies at http://www.microsoft.com/casestudies/search.aspx?Keywords=SOA

References

• "How To: Use Impersonation and Delegation in ASP.NET 2.0", August 2005, J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Andy Wigley, Kishore Gopalan, Patterns and Practices http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAGHT000023.asp
• "Authentication and Authorization", January 2004, Patterns and Practices http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod03.asp
• "Developing Identity-Aware ASP.NET Applications, Identity and Access Management Services, July 8th 2004. http://www.microsoft.com/technet/security/topics/identitymanagement/idmanage/P3ASPD_1.mspx