Security over the Internet is an on-going concern
that, when not addressed adequately, can be directly responsible for the
failure of service-oriented solutions, especially those that enable
business-to-consumer or business-to-business interaction.
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.
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).
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.
Note
The Laws of
Identity influenced the underlying architecture of the Identity
Metasystem. These laws are published at www.identityblog.com.