Windows Cardspace
Windows Cardspace is a part of
WIF that acts as an identity selector. A large underpinning of the
Windows Cardspace mechanisms is mutual authentication. Up to this point,
only the consumer of a security token has been required to provide
authentication. This is one of the main reasons phishing has been on the
rise. The Identity Metasystem provides a means for the consumer to also
authenticate the relying party to determine whether it wishes to
release identity information.
Windows Cardspace includes
a UI component that enables end-users to participate in the Identity
Metasystem and allows developers to build claims-based systems. Each
digital identity is displayed as an information card (or InfoCard). The
UI builds upon the WS-* enabled Identity Metasystem by allowing users to
select a security token that they can use for single-click logins into a
variety of systems.
With
Windows Cardspace, a user can have a digital card for each of their
digital identities. When a digital card is selected, the underlying STS
will generate the appropriate security token for the target system. This
allows the identity aspect to be abstracted out. When an identity is
selected using digital cards, the underlying system synthesizes the
appropriate security token. For example, if the target identity system
requires Kerberos tokens, the underlying STS will convert the selected
digital identity card to a security token based on the Kerberos format.
Therefore, Windows Cardspace can be used to log in to an identity system
using just one click.
The main components are:
identity provider– The identity provider includes an STS, SSL
certificates, and other features. It accepts user credentials,
authenticates users, and creates username tokens. An identity provider
also acts as an issuer of InfoCards. It can provide one or more token
types. It is based on WS-Trust and supports WS-SecurityPolicy to
exchange policy information.
relying party– A
relying party is a Web site or a Web service that requires identity
information. Amazon.com, eBay, or Web services exposed by a corporation
are examples of relying parties. A relying party uses
WS-MetadataExchange to exchange policy information. The policy itself is
based on WS-SecurityPolicy. Other terms used to describe a relying
party are “claims aware application” or “claims-based application.”
client or subject– The client or subject can be a browser or a
smart client application that releases the identity to the relying
party. The client controls and consents the release of identity. A
client can therefore have several cards and each card can have several
claims. When a user logs into the UI of a service-driven solution, the
user can provide it the appropriate card for the context.
In the traditional
model, the identity provider and the relying party are in the same
domain. With the federated identity model proposed by the Identity
Metasystem, the relying party can consume a token issued by an identity
provider in a different domain and all these systems are completely
decoupled.
Figure 4 shows the interaction between these roles. When the client
tries to connect to a relying party, it expresses requirements that must
be met to proceed. These requirements can include specifying an issuer
of the security token and various claims that the security token must
contain. When the claim requirement comes in from the relying party,
only the InfoCards that satisfy these claims light up in the Windows
Cardspace user interface.
Windows Cardspace reads
metadata from the InfoCard selected by the subject and contacts the
identity provider (the STS) for a security token. The data presented to
the identity provider includes metadata from the InfoCard and the list
of claims from the relying party. The identity provider sends the
appropriate security token to the subject, which in turn provides the
security token to the relying party. This mechanism decouples the
identity provider from the relying party and, unless explicitly
specified, the relying party does not need to know who the identity
provider is. The relying party makes authorization decisions based on
the claims provided to it in the security token.
An InfoCard can be either
self-issued or issued by an identity provider also known as a card
provider. A self-issued card obviously has a lower level of trust with
relying parties accepting it.
An InfoCard is a simple
file (with a .crd extension) that contains metadata, such as card name,
issuer name, images, expiry date, logo images, STS location, and
security token types supported. The STS location is a key data attribute
that links the card to an identity provider that can be used to
generate the appropriate security token. Data stored on the card is
minimal; any sensitive information, such as credit card number or social
security number, is stored securely in the STS by an identity provider.
A digital card is signed by and contains a certificate from the
identity provider. Windows Cardspace is security token-agnostic, meaning that
it simply acts as a conduit that allows security tokens to flow through
it.
A user’s computer may
contain rogue software that may steal InfoCards files. Windows Cardspace
is designed to be secure and mitigate this and similar threats.
Identity-related sensitive data is generally stored remotely with an
identity provider in a highly secure environment away from the client’s
computer. The cards only contain metadata used to render the card
information visually. In itself, an InfoCard does not contain any data
that the relying party requires. In order to acquire a security token,
the subject needs to authenticate itself with the identity provider
using a PIN or password.
InfoCards can be accessed
using WCF, any platform that is WS-* aware, or even via a Web browser.
The InfoCard service is a layer above the collection of cards that
exposes an API used by IE and WCF. For example, WCF uses an API
encapsulated in System.IdentityModel.Selectors
to access InfoCards on a client machine.
Active Directory
Federation Services (ADFS)
An STS is the plumbing
that builds, signs, and issues security tokens according to
inter-operable protocols. ADFS (also displayed with a space as “AD FS”)
2.0 is an implementation of an STS. ADFS is built upon WIF and provides
seamless access between on-premise software and loud services.
Active Directory and
Kerberos provide a single sign-on experience within a Windows domain in
an organization. Once a user signs into Windows, file servers, the mail
server, database servers, and other resources in the Windows environment
can be seamlessly accessed. Under the hood, the Kerberos subsystems on
the local computer and the Active Directory authenticate and authorize
the request to each resource.
ADFS extends the current
Active Directory across platform and organization boundaries. It allows
identity information to flow across these boundaries independent of the
platforms, solution environments, or security models. With ADFS, a
person can log on once and his or her digital identity can be projected
across authorization boundaries. These authorization boundaries can
separate a different organization or a different platform within the
same organization. With ADFS, each organization can maintain its own
repository; ADFS then allows different organizations to federate
identities across identity stores by providing an individual with a
single sign-on experience.
ADFS implements the
claims-based security model described earlier and uses WS-Trust,
WS-Security, WS-SecurityPolicy, and other WS-* specifications. It uses
HTTP as the transport for all communications.
