Export (0) Print
Expand All

Identify the Type of Federated Application to Deploy

Updated: January 31, 2008

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.

noteNote
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

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.

noteNote
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.

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.

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.

noteNote
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.

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.

ImportantImportant
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.

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 (http://go.microsoft.com/fwlink/?LinkId=107034).

noteNote
Previous versions of SharePoint products require the exclusive use of the default Web site in IIS.

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 (http://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) (http://go.microsoft.com/fwlink/?LinkID=84805).

noteNote
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.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft