As part of the process of designing your Active Directory Federation Services (AD FS) deployment, identify the type of federated application that you want to be secured by AD DS. For an application to be federated, the application must be at least one of the application types that are described in the following sections.

To learn more about improved application support in this version of AD FS, see What's New in AD FS in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=85684).

Claims-aware application

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

A claims-aware application is a Microsoft ASP.NET application that has been written using the AD FS class library. This type of application is fully capable of using AD FS claims to make authorization decisions directly. A claims-aware application accepts claims that the Federation Service sends in AD FS security tokens. For more information about how the Federation Service uses security tokens and claims, see Understanding the Federation Service Role Service.

Claim mapping is the act of mapping, removing or filtering, or passing incoming claims into outgoing claims. Claim mapping does not occur when claims are sent to an application. Instead, only the organization claims that are specified by the Federation Service administrator in the resource partner are sent to the application. (Organization claims are claims in intermediate or normalized form within an organization's namespace.) For more information about claims and claim mapping, see Understanding Claims.

The following list describes the organization claims that claims-aware applications can use:

  • Identity claims (UPN, e-mail, common name)

    When you configure the application, you specify which of these identity claims will be sent to the application. No mapping or filtering is performed.

  • Group claims

    When you configure the application, you specify the organization group claims that will be sent to the application. Organization group claims that are not designated to be sent to the application will be discarded.

  • Custom claims

    When you configure the application, you specify the organization custom claims that will be sent to the application. Organization custom claims that are not designated to be sent to the application will be discarded.

Claims-aware authorization

Claims-aware authorization consists of a Hypertext Transfer Protocol (HTTP) module and objects for querying the claims that are carried in the AD FS security token. Claims-aware authorization is supported only for Microsoft ASP.NET applications.

The HTTP module processes AD FS protocol messages based on configuration settings in the Web application's Web.config file. The Web pages perform authentication and authorization tasks. The HTTP module also authenticates cookies and obtains claims from the cookies.

Windows NT token–based application

A Windows NT token–based application is an Internet Information Services (IIS) application that has been written to use traditional Windows native authorization mechanisms. This type of application is not prepared to consume AD FS claims.

Windows NT token–based applications may be used by Windows users from the local realm or from any realm that is trusted by the local realm—that is, only by users who can log on to the computer with Windows NT token–based authentication mechanisms.

Note

In federation designs, this means that resource accounts or resource groups may be required for Windows NT token–based authentication.

The AD FS security token that is sent to the Windows NT token–based agent can contain any of the following types of claims:

  • A user principal name (UPN) claim for the user

  • An e-mail claim for the user

  • A group claim

  • A custom claim for the user

  • A UPN, e-mail, group, or custom claim containing the security identifiers (SIDs) of the user account. (This applies only when the Windows Trust option is enabled.)

The AD FS-enabled Web server generates a Windows impersonation-level access token. An impersonation-level access token captures the security information for a client process, which makes it possible for a service to "impersonate" the client process in security operations.

For Windows NT token–based Web applications, the following process order determines how a Windows NT token is created:

  1. If the Security Assertion Markup Language (SAML) token contains SIDs in the SAML advice element, the SIDs are used to generate the Windows NT token.

  2. If the SAML token does not contain SIDs and instead contains a UPN identity claim, the UPN claim is used to generate the Windows NT token.

  3. If the SAML token does not contain SIDs and the UPN identity claim in the e-mail identity claim is present, it is interpreted as a UPN and it is used to generate the Windows NT token.

This behavior is irrespective of whether the UPN or e-mail identity claim is specified as the identity claim that is used to generate the Windows NT token when you create the trust policy entry for the Web application in the Federation Service.

Traditional Windows-based authorization

Support for converting an AD FS security token into an impersonation-level Windows NT access token requires a number of components:

  • Internet Server Application Programming Interface (ISAPI) extension: This component checks for AD FS cookies, checks for AD FS security tokens from the Federation Service, performs the appropriate protocol redirects, and writes the necessary cookies to make AD FS work.

  • AD FS authentication package: The AD FS authentication package generates an impersonation-level access token, given a UPN for a domain account. The package requires that the caller have the Trusted Computing Base (TCB) privilege.

  • AD FS Web Agent and Federation Services URL property pages in the IIS Manager snap-in: You can use these property pages to administer policy and certificates for verifying the AD FS security token and cookies.

  • AD FS Web Agent Authentication Service: The AD FS Web Agent Authentication Service runs as Local System to generate a token by using either Service-for-User (S4U) or the AD FS authentication package. However, the Internet Information Services (IIS) application pool is not required to run as Local System. The AD FS Web Agent Authentication Service has interfaces that may be called only with local remote procedure call (LRPC), not remote procedure call (RPC). The service returns an impersonation-level Windows NT access token if it is given an AD FS security token or AD FS cookie.

  • AD FS Web Agent ISAPI Filter: Certain traditional IIS Web applications use an ISAPI filter that may modify incoming data, such as Uniform Resource Locators (URLs). If this is the case, the AD FS Web Agent ISAPI Filter must be enabled and configured as the highest priority filter. This filter is not enabled by default.

  • Adding Web Applications to the Federation Service
  • Add a Windows NT Token-Based Application