2.1.3 Identity and Directory Services

  • Article

A security token is a set of bytes that expresses information about a digital identity. When transmitted on the network, every digital identity is represented by a security token. The identity metasystem in CardSpace provides a consistent way to work with multiple digital identities, regardless of the kinds of security tokens that they use. Windows CardSpace uses the following three distinct roles:

  • Relying Party

  • Identity Provider

  • User

    Relying Party: The Relying Party is an application that in some way relies on a digital identity. A Relying Party frequently uses an identity to authenticate a user, and then makes an authorization decision, such as allowing that user to access information. A Relying Party accepts security tokens, defines policy by using WS-SecurityPolicy, and then allows the policy to be accessed by using WS-MetadataExchange.

    Identity Provider: An Identity Provider provides a digital identity for a user. Digital identities that are created by different identity providers can carry different information and provide different levels of assurance that the user really is who he or she claims to be. An Identity Provider creates information cards, provides a way to get these cards to users, and implements a security token service (STS), as defined by the WS-Trust specification.

    User: The User is the entity that is associated with a digital identity. Users are often people, but organizations, applications, machines and other things can also have digital identities.

The following diagram illustrates the interactions among Users, Relying Parties, and Identity Providers.

Interactions among Users, Relying Parties, and Identity Providers

Figure 8: Interactions among Users, Relying Parties, and Identity Providers

The following steps are involved in CardSpace communication:

  1. The process begins when a client accesses a protected resource on a Relying Party.

  2. The Relying Party sends its security token requirements to the client. This information is contained in the Relying Party's policy, and it includes information such as which security token formats the Relying Party accepts, and exactly what claims those tokens have to contain.

  3. After getting the details about the security token that the Relying Party requires, the client passes this information to CardSpace and the system displays the card selection screen. After the User clicks a particular card, CardSpace issues a request to the Identity Provider that is associated with that card.

  4. The Identity Provider then returns a security token to CardSpace.

  5. CardSpace gives the security token to the client, which in turn passes it to the Relying Party.

CardSpace can be used from browsers as well as from WCF applications.

Information cards and the identity metasystem are documented in Identity Metasystem Interoperability V1.0 [IMI].

The Microsoft .NET Framework provides support for applications that require access to network directory services through the Microsoft extensions to the directory services markup language.

[MS-DSML] is known as the SOAP session extension (SSE) of Microsoft extensions to the Directory Services Markup Language (DSML) 2.0 Protocol. It provides for the creation of a session, association with a particular session, and a way to terminate the session.