Appendix C: Documenting Your ADFS Design
Applies To: Windows Server 2003 R2
You can use the following tables to document the various details of your Active Directory Federation Service (ADFS) design. Make sure that the role your organization plays in the federation agreement is clearly understood by all parties:
If your organization is a resource provider, determine the application types and the organization claims for the organization, as well as the incoming claims for each account partner. In addition, if the resource that you are providing is a Windows NT token–based application, determine the resource accounts and groups (also known as shadow accounts or proxy groups) that will be mapped.
If your organization is an account provider or identity provider, determine the account stores and the claim extractions for the organizations, as well as the outgoing claims for each resource partner.
If your organization is both an account provider and a resource provider, document the requirements in the tables in all the following sections.
Deployment goals
Understanding the ADFS functionality that you want to enable can help you select the appropriate goals for your deployment. For each of the areas of functionality in the following table, specify whether or not your scenario requires them.
| Functionality | Yes/No |
|---|---|
Provide federated access for your hosted applications |
|
Provide federated access for your employees on the corporate network |
|
Provide federated access for your remote employees on the Internet |
|
Provide single-sign-on access for customers to your hosted applications |
The following table is an example of documented deployment goals.
| Functionality | Yes/No |
|---|---|
Provide federated access for your hosted applications |
Yes |
Provide federated access for your employees on the corporate network |
Yes |
Provide federated access for your remote employees on the Internet |
No |
Provide single-sign-on access for customers to your hosted applications |
No |
Resource applications
If your organization is hosting an application or multiple applications, use the following table to document the applications and application types that will be part of your ADFS deployment.
| Application name | Application type |
|---|---|
The following table is an example of documented resource application requirements.
| Application name | Application type |
|---|---|
Purchasing Portal |
Windows NT token–based |
Ordering Application |
Claims-aware |
Sales Reports Application |
Windows NT token–based |
Account stores
If your organization is hosting account stores, use the following table to document the account stores that will be used to access the applications.
| Account store | Account store type (internal, partner, hosted) |
|---|---|
The following table is an example of documented account store requirements.
| Account store | Account store type (internal, partner, hosted) |
|---|---|
Corporate Active Directory |
Internal account store (corporate network access) |
Trey Research Employees |
Federation account partner |
Consolidated Messenger Customers |
Hosted account store |
Organization claims
Organization claims are the normalized set of claims on the federation server. Use the following table to document the organization claims and claim types on your federation server.
| Organization claim | Claim type (identity, group, custom) |
|---|---|
The following table is an example of documented organization claim requirements.
| Organization claim | Claim type (identity, group, custom) |
|---|---|
Administrators |
Group |
Purchasers |
Group |
Power Purchaser |
Group |
PurchaseLimit |
Custom |
EmployeeID |
Custom |
Claim extractions
Claim extractions map a user or group in an account store to an organization claim. The account store can be Active Directory or Active Directory Application Mode (ADAM). If your organization is an account partner, use the following table to document the Active Directory users or groups for claim extractions and their corresponding organization claims.
| Active Directory user or group | Organization claim |
|---|---|
The following table is an example of documented claim extraction requirements.
| Active Directory user or group | Organization claim |
|---|---|
Purchase Administrators |
Administrators (Group) |
Sales Managers (Group) |
Purchasers (Group) |
EmployeeID (Attribute) |
EmployeeID (Custom) |
John Smith (User) |
Power Purchaser (Group) |
Outgoing claims
Organization claims on the federation server of the account partner are mapped to outgoing claims that are sent to the resource federation server. If your organization is an account partner, use the following table to document the organization claims and their corresponding outgoing claims.
| Organization claim | Outgoing claim |
|---|---|
Note
Organization claims and outgoing claims can have the same names if it is not necessary for the claim names to be different.
The following table is an example of documented outgoing claim requirements.
| Organization claim | Outgoing claim |
|---|---|
Administrators |
Admins |
Purchasers |
Allowed Purchasers |
Power Purchaser |
Power Purchaser |
PurchaseLimit |
PurchaseLimit |
EmployeeID |
EmployeeID |
Incoming claims
Incoming claims are received by the resource federation server from the account federation server. When incoming claims are received by the resource federation server, they are mapped to organization claims on the resource federation server. If your organization is a resource partner, use the following table to document the incoming claims and their corresponding organization claims.
| Incoming claim | Organization claim |
|---|---|
The following table is an example of documented incoming claim requirements.
| Incoming claim | Organization claim |
|---|---|
Admins |
Purchase Admins |
Allowed Purchasers |
Allowed Purchasers |
Power Purchaser |
Power Purchaser |
PurchaseLimit |
PurchaseLimit |
EmployeeID |
Employee Identity |
Note
Incoming claims and organization claims can have the same names if it is not necessary for the claim names to be different.
Windows NT token–based application users and groups
When the resource application is a Windows NT token–based application, the organization claims on the resource federation server must be mapped to either a user or a group in Active Directory. If your organization is a resource partner that hosts a Windows NT token–based application, use the following table to document the organization claims and the Active Directory users or groups that the claims must map to.
| Organization claim | Active Directory user or group |
|---|---|
The following table is an example of documented requirements for users or groups that use a Windows NT token–based application.
| Organization claim | Active Directory user or group |
|---|---|
Purchase Admins (group) |
Purchase Admins (group) |
Allowed Purchasers (group) |
Purchasers (group) |
Power Purchaser (group) |
Power Purchaser (user) |