Appendix B: Reviewing Key AD FS Concepts

  • Article

Applies To: Windows Server 2008

This appendix briefly explains the following key Active Directory Federation Services (AD FS) 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 AD FS:

  • 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 AD FS deployment, the server authentication certificates for the various AD FS 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 AD FS 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 Enterprise PKI Concepts (https://go.microsoft.com/fwlink/?LinkId=108558).

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 AD FS, there are several claim types:

  • Identity: An identity claim defines the user or security principal that the claim set belongs to. AD FS 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 AD FS, 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 AD FS 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 AD FS Design to define the claims that will be used by your federation servers.

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

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 user interface (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 AD FS software development kit (SDK) on the MSDN Web site for additional information about how the claim transformation module functions (https://go.microsoft.com/fwlink/?LinkId=93719).

Account stores

AD FS 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 AD FS 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 AD FS to support the user identities. AD FS can use either Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Services (AD LDS) 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:

  • Provide federated access for your employees on the corporate network: Your organization’s users access an AD FS-secured application (either your own application or a partner’s application) when the users are logged on to the corporate intranet. For more information, see Provide Federated Access for Your Employees on the Corporate Network.

  • Provide federated access for your remote employees on the Internet: Your organization’s users access an AD FS-secured application (either your own application or a partner’s application) when the users are logged on to the corporate intranet and when they log on from the Internet. For more information, see Provide Federated Access for Your Remote Employees on the Internet.

  • Provide single sign-on access for customers to your hosted applications: Your organization hosts external user accounts that must access an AD FS-secured application at your organization. For more information, see Provide SSO Access for Customers to Your Hosted Applications.

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

Note

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

Using AD LDS

The following list describes things you should know about using AD LDS with AD FS:

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

  • AD FS cannot authenticate AD LDS 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 AD LDS server and the federation server be protected by TLS/SSL or other means, such as Internet Protocol security (IPsec).

  • AD LDS 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).

  • AD LDS 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 AD FS 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 AD FS 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).