Freigeben über


Claims

Applies To: Windows Server 2003 R2

Claims are statements (for example, name, identity, key, group, privilege, or capability) made about users — and understood by both partners in an Active Directory Federation Service (ADFS) federation — that are used for authorization purposes in an application.

The Federation Service brokers trust between many disparate entities. It is designed to allow the trusted exchange of arbitrary claims containing arbitrary values. These claims are then used by the receiving party to make authorization decisions.

There are three ways that claims flow through the Federation Service:

  • From the account store to the account Federation Service to the resource partner

  • From the account partner to the resource Federation Service to the application resource

  • From the account store to a Federation Service to the application resource

The Federation Service can be configured to act in all three of these roles. Therefore, one single Federation Service may facilitate all three communication flows.

There are three types of claims that are supported by the Federation Service: identity claims, group claims, and custom claims. The following table describes each of these claim types in more detail.

Claim type Description

Identity

UPN, e-mail, and common name in ADFS are referred to as identity claim types.

  • UPN — Indicates a Kerberos-style user principal name (UPN), for example: user@realm. Only one claim may be the UPN type. Even if multiple UPN values must be communicated, only one may be of the UPN type. Additional UPNs may be configured as custom claim types.

  • E-mail — Indicates RFC 2822–style e-mail names of the form user@domain. Only one claim may be the e-mail type. Even if multiple e-mail values must be communicated, only one may be of e-mail type. Additional e-mails may be configured as custom claim types.

  • Common name — Indicates an arbitrary string that is used for personalization. Examples include John Smith or Tailspin Toys Employee. Only one claim may have the common name type. It is important to note that there is no mechanism for guaranteeing the uniqueness of the common name claim. Therefore, use caution when using this claim type for authorization decisions.

Group

Indicates membership in a group or role. Administrators define individual claims that have the group type “Group claims.” For example, you might define the following set of group claims: [Developer, Tester, Program Manager]. Each group claim is a separate unit of administration for claim population and mapping. It is useful to think of the value of a group claim as a Boolean value indicating membership.

Custom

Indicates a claim that contains custom information about a user, for example, an employee ID number.

If more than one of the three identity claim types is present in a token, the identity claims are prioritized in the following order:

  1. UPN

  2. E-mail

  3. Common name

At least one of these identity claim types must be present for a token to be issued.

Auditing claims

Some group claims and custom claims may be designated as auditable. When auditing is enabled, the audit allows the name of the claim to be exposed in the security event log, but the value of the claim is omitted. An example of an auditable claim is Social Security Number. The claim name Social Security Number is exposed, but the actual number value that is stored in that claim is not exposed. The claim value is not audited when the claim is produced or mapped.

Note

Identity claim types are always auditable.

Claim producers and consumers

The way claims are used depends on the claim producer or consumer. Claims are either inbound or outbound. ADFS supports the following claim producers and consumers:

  • Active Directory account stores

  • ADAM account stores

  • Account partners

  • Resource partners

  • Claims-aware applications

  • Windows NT token–based applications

Active Directory account store

The Active Directory account store is a claim producer that represents authentication for the Federation Service. Specifically, the Federation Service may log on users from its domain, from domains that are directly trusted by its domain, from domains in the same forest as its domain, and from domains in forests that have forest trusts with the domain’s forest.

The Active Directory account store is available only if the Federation Service is joined to a domain.

  • UPN claim: When you configure the Active Directory account store, the UPN claim is enabled automatically.

  • E-mail claim: When you configure the Active Directory account store, you can specify what Lightweight Directory Access Protocol (LDAP) user attributes, if any, contain the user’s e-mail address.

  • Common name claim: When you configure the Active Directory account store, you can specify what LDAP user attributes, if any, contain the user’s common name.

  • Group claims: you can assign Windows users and groups directly to the organization group claims using the object picker.

  • Custom claims: When you configure the Active Directory account store , you can specify what LDAP user attributes contain claim values and then assign each attribute name to an organization custom claim.

ADAM account store

The ADAM account store is a claim producer that represents authentication for the Federation Service.

  • UPN claim: When you configure the ADAM account store, you can specify the LDAP user attribute, if any, containing the user’s UPN.

  • E-mail claim: When you configure the ADAM account store, you can specify the LDAP user attribute, if any, containing the user’s e-mail address.

  • Common name claim: When you configure the ADAM account store, you can specify the LDAP user attribute, if any, containing the user’s common name.

You must assign at least one identity claim type to the ADAM account store for the Federation Service to allow that store to be enabled.

  • Group claims: When you configure the ADAM account store, you can specify the LDAP user attribute containing the user’s LDAP groups or any other attribute that could function as a group, such as Title (if groups are based on job role), and then assign each possible LDAP group to an organization group.

  • Custom claims: When you configure the ADAM account store, you can specify the LDAP user attributes containing claim values. You then assign each attribute name to an organization custom claim.