Share via

Appendix B: Reviewing Key ADFS Concepts

  • Article

Applies To: Windows Server 2003 R2

This appendix briefly explains the following key Active Directory Federation Services (ADFS) concepts:

  • Certificate sources

  • Claim definitions

  • Claim transformation module

  • Account stores

  • Port configurations

Certificate sources

There are three sources for the certificates that you use with ADFS:

  • A certification authority (CA) that is deployed in your organization

  • A third-party CA

  • Self-signed certificates

Each certificate source has advantages and disadvantages that are described in the following sections.

CA in your organization

When you implement a CA in your organization, you create a robust infrastructure that provides life-cycle management, renewal, trust management, and revocation for all the certificates in your organization, at the cost of having to deploy additional infrastructure.

Third-party CA

Certificates that are generated by a third-party CA have many of the benefits of implementing a CA in your organization. However, third-party certificates must be purchased. Of the certificates that are used in an ADFS deployment, the server authentication certificates for the various ADFS components are frequently third-party certificates. This makes it possible for client browsers to be configured in advance to trust the certificates.

Self-signed certificates

Self-signed certificates do not require the presence a CA. You must configure these certificates explicitly in certain locations on the server as trusted certificates. It is more difficult to establish an infrastructure for certificate life-cycle management, renewal, trust management, and revocation with self-signed certificates.

The various types of certificates that ADFS uses can come from any combination of these three sources. For example, you may find that your server authentication certificates are obtained from a third-party CA, but your token-signing certificate is obtained from your organization’s CA.

For more information about certificates, see Public Key Infrastructure for Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=19936).

Claim definitions

Claims are statements that a federation server makes about a user. They are used by Web applications to make authorization decisions. Claims originate from either a local account store or an account partner.

In ADFS, there are several claim types:

  • Identity: An identity claim defines the user or security principal that the claim set belongs to. ADFS supports three types of identity claims:

    • User principal name (UPN)

    • E-mail

    • Common name

  • Group: This claim type indicates membership in a group or role. 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: This claim type is a name-value pair. For example, a custom claim may indicate that a user’s employee ID number is 1234.

In ADFS, there are several types of groupings of claims:

  • Organization claims: These are claims that serve as the normalized set of claims within an organization. All internal Federation Service actions are performed on the organization claim set.

  • Incoming claims: These are claims that a specific account partner sends to your organization.

  • Outgoing claims: These are claims that your organization sends to a specific resource partner.

When you design an ADFS deployment, it is necessary to understand how the claims will be extracted from the account store into the organization claim set, transformed at both the account federation server and the resource federation server, and then ultimately presented to the Web application. You can use the tables in Appendix C: Documenting Your ADFS Design to define the claims that will be used by your federation servers.

The flow of claims through an ADFS deployment is depicted in the following illustration.

The claim mapping process

For more information about the role that claims play based on the organization they are being used in, see the following topics:

Claim transformation module

You can use the Active Directory Federation Services snap-in on your federation servers to map claim names between the various transitions that are highlighted in the previous figure. You can use this UI to change the name of a claim during the mapping; for example, Administrators may become Admins. This way, you can share claims with partners and express claims in a common namespace that does not necessarily match the way that you have defined your own organization claims.

There may be situations, though, in which a simple mapping of claims may not be sufficient for your scenario. For these situations, you can develop a claim transformation module that modifies claim names and values as they pass through the federation server. For example, the claim transformation module might convert a claim containing a monetary value in one currency into another currency based on an exchange rate. Or, the claim transformation module might look into a sales database and determine the discount level for a partner.

If you determine that building a claim transformation module is necessary for your scenario, see the ADFS software development kit (SDK) on the MSDN Web site for additional information about how the claim transformation module functions. To find the ADFS SDK, search for "ADFS SDK" on the MSDN Home page (https://go.microsoft.com/fwlink/?LinkId=16188).

Account stores

ADFS requires an account store to authenticate users. The Federation Service uses Lightweight Directory Access Protocol (LDAP) to communicate with an account store. The account store also generates a claim set so that applications can make authorization decisions. In most situations the account store that ADFS will use has already been deployed and is populated with users.

The location of the user account store and the location from which users authenticate determine how you design ADFS to support the user identities. ADFS can use either Active Directory or Active Directory Application Mode (ADAM) as an account store. Depending on where the account store is located and where users will access the application (in an intranet or on the Internet), you can use one of the following options for the location of the account store:

Depending on the requirements of your organization, you can combine several of these account store options to complete the design of your ADFS deployment.

Note

The Active Directory domain functional level may be set to either Windows 2000 mixed, Windows 2000 native, or Windows Server 2003.

Using ADAM

The following list describes things you should know about using ADAM with ADFS:

  • ADAM does not support SSL client authentication because it is implemented using a secure channel.

  • ADFS cannot authenticate ADAM accounts that use parentheses as part of the account name. Accounts that have an open parenthesis in the user name cause an LDAP search failure as a result of the user name forming an invalid LDAP filter.

  • We strongly recommend that the traffic between the ADAM server and the federation server be protected by TLS/SSL or other means, such as Internet Protocol security (IPsec).

  • ADAM is typically used as an account store in the Web Single-Sign-On (SSO) design when you are deploying only claims-aware applications (not Windows NT token–based applications).

  • ADAM cannot be used in the resource partner when you are deploying a Windows NT token-based application that requires resource account mapping methods. For more information about resource account mapping methods, see Determine your resource account mapping method.

Application user store requirements

Windows NT token–based applications require the presence of an Active Directory local user store to generate a user context for the application. Claims in incoming ADFS tokens can be mapped into either user accounts or groups within this local user store. The user accounts or groups are then used by the application to perform authentication.

Claims-aware applications do not require a local user store. All information about a given identity is contained in the token that is presented by the application. The application may store additional information that links to the identity that is presented in the token, but a user account in Active Directory is not required.

Port configurations

Because ADFS serves Web browser clients over Secure Hypertext Transfer Protocol (HTTPS), connectivity through HTTPS must be available to the federation servers and federation server proxies. The default port for HTTPS is port 443, but other port numbers may be configured depending on your IIS configuration. Your firewalls between clients and federation servers or federation server proxies must be configured to allow HTTPS traffic.

Just as clients need HTTPS connectivity to the federation server, the federation server proxy requires HTTPS connectivity to the federation server.

If any certificate that you use has certificate revocation lists (CRLs), the server with the configured certificate must be able to contact the server that distributes the CRLs. The type of CRL determines that ports that are used.

For information about the port requirements for the Federated Web SSO with Forest Trust design, see How Domain and Forest Trusts Work (https://go.microsoft.com/fwlink/?LinkId=35356).