Identify the Type of Federated Application to Deploy
Applies To: Windows Server 2008
As part of the process of designing your deployment, identify the type of federated application that will be secured by Active Directory Federation Services (AD FS). All applications that are secured by Windows Server 2008 AD FS Web Agents must be running under Internet Information Services (IIS) 7.0.
Note
Applications that require special client software or that are used for server-to-server communication are not good candidates for AD FS authentication.
So that they can use AD FS Web Agents, each application must be at least one of the following application types:
Claims-aware application: Claims-aware applications are Microsoft ASP.NET 2.0 applications that are written so that they can query AD FS security token claims. When a claims-aware application is presented with a valid token, the application can make authorization decisions based on the claims in the token.
Windows NT token–based application: Windows NT token–based applications use Windows-based authorization mechanisms. These applications require Windows NT security tokens to make authorization decisions. AD FS can enable the transition of an AD FS security token to an impersonation-level, Windows NT access token.
The following table shows the differences in requirements for each type of federated application.
| Requirements and other factors | Claims-aware application | Windows NT token–based application |
|---|---|---|
Requires the application to be written using ASP.NET 2.0 |
Yes |
No |
Requires a user account in Active Directory Domain Services (AD DS) |
No |
Yes |
Requires a local Active Directory user store (to generate a user context for the application) |
No |
Yes |
Requires Windows-based authorization mechanisms (such as access control lists (ACLs)) |
No |
Yes |
Requires resource accounts or groups |
No |
Yes |
Supported with ASP.NET 1.1 |
No |
Yes |
Requires a web.config file |
Yes |
No |
Can handle claims within the application code |
Yes |
No |
Can use Authorization Manager for access control |
Yes |
No |
Claims-aware applications
When you set up a claims-aware application, all the 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 AD DS is not required to access a claims-aware application.
Federated applications that are claims aware should be developed specifically to use the claims that are produced by AD FS. When an application is presented with a valid token, the claims-aware application can make authorization decisions based on the claims in the token.
For more information about how to deploy a claims-aware application, see Checklist: Installing a Claims-Aware Application.
Note
When you configure the Web server to host only claims-aware applications, you do not have to provide values on any of the AD FS Web Agent tabs in the property sheets in IIS Manager.
Integrating with Authorization Manager
Claims-aware applications can take advantage of role-based access control applications, such as Authorization Manager. Authorization Manager provides a flexible framework for integrating role–based access control into applications. Administrators who configure claims-aware applications can use Authorization Manager to provide access through assigned user roles that relate to job functions.
Authorization Manager applications maintain authorization policy in the form of authorization stores in AD DS or XML files. The stores apply authorization policy at run time. For more information about AD FS and Authorization Manager, see When to Use Authorization Manager.
Windows NT token–based applications
When you set up a Windows NT token–based application, you can map claims in incoming AD FS tokens to either user accounts or groups in the local Active Directory user store in the resource partner. The user accounts or groups are also known as resource accounts or resource groups. The application then uses the resource accounts or groups to perform authorization. For more information about resource accounts, see When to Use Resource Accounts.
Applications that are protected by Windows Integrated authentication can—in some cases—be enabled as Windows NT token–based applications.
For more information about how to deploy a Windows NT token–based application, see Checklist: Installing a Windows NT Token-Based Application.
Note
Because the AD FS Web Agent for Windows NT token–based applications implements authentication functions as an Internet Server Application Programming Interface (ISAPI) extension, an application that requires authentication in an ISAPI filter cannot be protected by AD FS.
Using SharePoint products as federated applications
With AD FS in Windows Server 2008, you can use either Microsoft® Windows® SharePoint® Services, Microsoft Office SharePoint Portal Server 2003, or Office SharePoint Server 2007 as supported federated applications. However, the level of support that AD FS provides depends largely on which SharePoint application you deploy.
Important
Before you deploy a specific SharePoint product for use with AD FS in your production environment, you should first read the following sections and the linked content to determine which SharePoint product best suits the needs of your organization when you use it as a federated application.
Using AD FS with previous versions of SharePoint products
Windows SharePoint Services 2.0 and SharePoint Portal Server 2003 are considered to be Windows NT token–based applications as a result of their reliance on basic Windows-based authorization mechanisms. Because these SharePoint products depend on Windows-based access control, certain functionality will not be available when either Windows SharePoint Services 2.0 or SharePoint Portal Server 2003 are used as federated applications.
For more information about which functionality is supported in previous SharePoint products, see article 912492 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=107034).
Note
Previous versions of SharePoint products require the exclusive use of the default Web site in IIS.
Using ADFS with current versions of SharePoint products
Windows SharePoint Services 3.0 and Office SharePoint Server 2007 products can be configured as claims-aware applications as a result of their support for membership and role provider authorization mechanisms. Because these versions of SharePoint products can use membership and role-based access control, they do not require that resource accounts be created or used in the resource partner organization to take advantage of the single-sign-on (SSO) capabilities that are integrated into AD FS. This means that you can configure Windows SharePoint Services 3.0 and Office SharePoint Server 2007 as claims-aware applications for use with AD FS by using the SharePoint site administration page to configure membership and role-based access control permissions directly. AD FS in Windows Server 2008 automatically provides built-in support for these current SharePoint products to help provide the best out-of-box experience, without additional updates.
For more information, see article 920764 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=107036).
For more information about how to configure Office SharePoint Server 2007 as a federated application, see Configure Web SSO authentication by using AD FS (Office SharePoint Server) (https://go.microsoft.com/fwlink/?LinkID=84805).
Note
Although current versions of SharePoint products do not require the exclusive use of the default Web site in IIS, Windows SharePoint Services 3.0 and Office SharePoint Server 2007 do require the exclusive use of port 80. For this reason, installing these SharePoint products will automatically disable the default Web site in IIS. You can, however, enable the default Web site at a later time after you reassign the port number to something other than port 80.