SOA Security with .NET and Windows Azure : Windows Identity Foundation (part 1) - Digital Identity

Because the Internet was not designed with a security layer, there are various security technologies and techniques available. When poorly implemented, they can result in phishing scams and identity theft. The IT industry at large is trying to solve this problem by creating a layer of abstraction or indirection across the entire Internet so as to enable an identity that anyone can use. The abstraction is being developed using industry-standard protocols and is commonly referred to as the Identity Metasystem (explained separately in an upcoming section).

On the Windows platform, the Identity Metasystem is implemented in the Windows Identity Foundation or WIF. It is a framework for establishing claims-based identity in services and service compositions. WIF can be used in any services based on the .NET Framework version 3.5 SP1 or higher. Active Directory Federation Services (ADFS) 2.0 (previously known as “Geneva” Server), Windows CardSpace 2.0, and Windows Identity Foundation (previously known as “Geneva” Framework) form the core of Microsoft’s claims based Identity Metasystem.

WIF is another major building block of the .NET framework (Figure 1) and is available on Windows 7, Windows Vista, Windows 2003, and Windows XP.

Figure 1. Windows Identity Framework was introduced with .NET 3.0.

In order to understand WIF, the best place to start is digital identity.

Digital Identity

Digital identity is a set of claims in a security token that express properties about a subject or user. It identifies a person or a thing in the digital environment where identities are managed differently by different organizations. For example, an individual may have a Yahoo e-mail account, login access to Amazon, and login access to eBay. He or she may also have a network login account at an organization, in which case the identity is stored in Active Directory.

A claim is a statement describing a characteristic of a digital identity. Each digital identity is expressed as a set of claims. All claims describing an identity are put together as a string or an XML document referred to as a security token. A simple security token can contain only one claim, such as username, while a more complex security token will contain many claims, including first name, last name, e-mail address, roles, etc.

Security tokens can be contained within application-level messages and passed around with these messages. Therefore, a service consumer can attach a security token to a message and send it to a service, which then decides if it wants to process the message based on the assertions made by the provided claims.

The Identity Metasystem

There is no consistent way of dealing with digital identities and it is impractical to assume that digital identities will be implemented in a standard way across all organizations and Web sites. In order to interoperate across different secured solutions, the industry proposed an identity layer that resides above the existing security systems and provides secure, industry standardized interoperability. This identity layer is known as the Identity Metasystem.

A consortium of vendors, including Microsoft, developed the Identity Metasystem using XML and Web services standards, including:

• WS-Security

• WS-Trust

• WS-MetadataExchange

• WS-SecurityPolicy

For a service consumer to send to a service a message that includes a security token, the service consumer must know the claims the service requires. The service can publish a policy describing the claims required. Based on this policy, the service consumer will attach a security token to messages it sends to the service. Such a policy supports Service Discoverability by allowing the service consumer to know ahead of time all the claims required to publish messages and to better understand the service’s requirements.

However, not all service consumers may have the mechanism to construct security tokens based on claims required by a service. The Identity Metasystem introduces the concept of the Security Token Service (STS) to address this issue. The STS is used to create security tokens and translate security tokens from one type to another. The service consumer can now communicate with an STS to acquire the appropriate security token it requires to interact with the service (Figure 2).

Figure 2. The service consumer gets the security policy from the service (1); then acquires the security token from the STS (2), and finally passes the token to the service (3).

An STS implementation is security token format agnostic. It provides claims translation and can transform any incoming security token to the desired format using extensibility features, thereby acting as a universal translator of security tokens. For example, an STS can take a custom username and password security token and return an X509 certificate, it can take an X509 certificate and provide an SAML token, and so on. An Identity Metasystem based on an STS-enabled claims-based architecture allows you to connect disparate systems with different security implementations.

At the core of the Identity Metasystem is the WS-Security standard that enables several different types of security tokens. The ability to encode various security tokens in WS-Security forms the basis of the STS. The Identity Metasystem can also leverage WS-MetadataExchange and WS-SecurityPolicy within the WS-* architecture stack for the discovery and definition of policies. Figure 3 shows how various WS-* technologies can be used to enable an Identity Metasystem.