Planning for federation server capacity

Applies To: Windows Server 2003 R2

Capacity planning for federation servers helps you estimate the following:

• The appropriate hardware requirements for each federation server

• The number of federation servers to place in each organization

Federation servers issue security tokens to users. These tokens are presented to a relying party for consumption. Federation servers issue security tokens after authenticating a user or after receiving a security token that was previously issued by a partner Federation Service. A security token is requested from a Federation Service when users initially sign in to federated applications or when their security tokens expire while they are accessing federated applications.

Federation servers are designed to accommodate high-availability server farm configurations that use Microsoft Network Load Balancing (NLB) technology. Federation servers in a farm configuration can service requests independently, without accessing any common farm components for each request. Therefore, there is little overhead involved in scaling out a federation server deployment.

Recommendations

• For mission-critical or high-availability deployments, we recommend that you create a small federation server farm in each partner organization, with at least two federation servers per farm, to provide fault tolerance.

• With the need for high availability and the ease of scaling out federation servers, scaling out is the recommended method for handling high numbers of requests per second for a particular Federation Service. Scaling up beyond the base configuration in this guide is unlikely to produce significant capacity handling gains.

Estimating hardware requirements

Fortunately, memory and disk space requirements for federation servers are modest, and they are not likely to be a driving factor in hardware decisions. Memory and disk space requirements for federation servers depend largely on the type of entry—such as claims, applications, or partners—that is made to the trust policy and the number of entries for each type of entry.

As the number of claim, application, and partner entries in the trust policy grow, so does the need for more memory. The following table contains general size requirements for each type of trust policy entry as tested by the Microsoft Active Directory Federation Services (ADFS) product team.

Memory and disk size requirements for trust policy entries

These requirements vary based on the configured content of each claim, application, and partner. Consider them to be general guidelines.

It is important to note that, using a minimal trust policy, the memory usage of the federation server is approximately 35 megabytes (MB). Therefore, add all calculated memory requirements on top of this base memory footprint. Whenever the trust policy is changed, a new copy of the trust policy is loaded into memory while the old copy remains active. After the new copy is loaded in its entirety, the old copy is removed. Therefore, when the trust policy is changed, the memory requirements of the service will briefly double.

Recommendation

• If your ADFS deployment involves a particularly large trust policy, double your calculations of the memory requirements to account for trust policy changes.

Example

You decide that your organization needs a trust policy that contains 45,000 organization group claims, 9,000 applications, and 30 account partners with 5 group claim mappings per partner. Based on actual testing by the ADFS product team, the trust policy file size is about 28 MB with this number of entries. Memory usage for this trust policy is approximately 130 MB (adding about 95 MB to the minimum federation server memory footprint of 35 MB). When you change the trust policy, memory usage is approximately 200 MB. A server with 1 GB of RAM should be able to handle this trust policy configuration, in addition to any other operating system requirements.

Capacity recommendations for federation servers can vary considerably, depending on whether the federation server is acting in the account federation server role or resource federation server role.

Account federation server capacity considerations

An account federation server issues security tokens to users based on user authentication. The server authenticates a user, pulls the relevant attributes and group membership out of the account store, creates and signs a security token, and then sends the security token to the user. The security token is ultimately consumed by a resource federation server. Account federation server capacity is measured in terms of the peak number of these user sign-ins.

When you estimate the expected peak number of user sign-ins per second, one important factor is the token-caching lifetime. Consider adjusting the default values for the token-caching lifetime in the resource Federation Service for the Web application. A longer token-caching lifetime results in fewer overall sign-ins and token requests at the account federation server. We do not recommend token cache lifetimes that exceed the token expiration time of the account federation server.

For more information about how to adjust values for the token-caching lifetime, see Configuring ADFS Servers for Troubleshooting (https://go.microsoft.com/fwlink/?LinkID=74970).

Gathering log data from the resource partner

Determining accurate capacity requirements for account federation servers can be challenging because the applications that require security tokens from an account federation server are often located in another organization.

If your organization does not have access to the application that currently logs application sign-ins, you may have to request estimates or logs from the organization that does have access to the application so that you can more accurately assess your capacity requirements.

After you have all the application logs, analyze them for peak numbers of user sign-ins. Estimate the peak number of sign-ins per second.

Determining peak sign-in capacity

The following table shows test lab results for the hardware that was used by the ADFS product team at Microsoft. The table indicates the peak number of sign-in requests that were made to an account federation server, along with their impact on CPU consumption.

Peak sign-ins per second for the account federation server

You can use the numbers in this table to help calculate how many account federation servers you must have to handle the expected peak sign-ins per second. Administrators for most production deployments are interested in lower CPU usage. They can scale out their hardware accordingly.

Recommendation

• If the expected value for peak sign-in requests per second for each server in your farm exceeds the peak value in the previous table, we recommend that you add additional federation servers until the expected number of peak sign-ins per second is well under this peak value for each server in the farm.

Example

Your organization has 36,000 employees that arrive between 8:00 A.M. and 9:00 A.M. on Monday mornings. The employees typically access a federated Web application to display their 401(k) information soon after arriving to work. It is important to analyze actual logs of the 401(k) application access to determine peak usage. Analysis of the 401(k) application logs indicates peak usage of 200 sign-ins per second between 8:55 A.M. and 9:00 A.M. The account federation server is configured to authenticate employees using Windows Integrated authentication. If 200 sign-ins per second is the peak usage of the overall system, the previous table indicates that a load-balanced federation server farm, containing at least three federation servers with hardware similar to the hardware that was used in the ADFS product team tests, can adequately handle the load and guarantee high availability, while leaving room for future growth in usage.

Resource federation server capacity considerations

A resource federation server typically issues security tokens to users based on the security tokens that it receives from an account federation server. After the resource federation server receives a security token, it verifies the signature, maps the claims based on its trust policy, creates a new security token, signs the new security token, and then sends token to the user. Ultimately, the security token is consumed by the federated application.

If your federation server is acting in an account role as well as a resource role, use the capacity planning numbers in the "Account federation server capacity considerations" section because user authentication is more expensive than validating security tokens.

Gathering log data

To estimate your resource federation server’s peak number of sign-ins per second more precisely, gather and analyze the historical logs of the applications to which users will be signing in. After you have all the application logs, analyze them for peak numbers of user sign-ins.

An important factor that influences the peak number of sign-ins is the configuration of token-caching lifetimes at the resource Federation Service and the Web application. Longer token-caching lifetimes result in less sign-ins at the Federation Service. Each time a new browser session is initiated, a new sign-in occurs.

Determining peak sign-in capacity

The following table shows test lab results that the ADFS product team used to measure peak capacity of sign-in requests to a resource federation server, along with their impact on CPU consumption.

Peak resource partner sign-ins per second for the resource federation server

You can use the numbers in this table to help calculate how many resource federation servers you need to handle the expected peak sign-ins per second.

Recommendation

• If the expected value for peak sign-in requests per second for each server in the farm exceeds the peak value shown in the previous table, we recommend that you add additional federation servers until the expected number of peak sign-ins per second is well under the value in this table for each server in the farm.

Example

Your organization hosts three federated Web applications for account partners to access. Before the ADFS deployment, account partner users were required to log in separately to each application. Analysis of the logs indicates that sign-ins peaked at 30, 50, and 60 sign-ins per second at each application, respectively. Further analysis shows that each application experiences its peak usage at the same time each day. The aggregated number of sign-ins per second is 140. While the single sign-on (SSO) that is provided by the Federation Service reduces the sign-ins that users perceive, the Federation Service must still issue a security token for each application. Therefore, 140 sign-ins per second is a safe number to use as an estimate. The data in the previous table indicates that 140 sign-ins per second can be handled easily by a high-availability deployment of a small, load-balanced federation server farm containing at least two federation servers with hardware similar to the hardware that was used in the ADFS product team tests—while leaving room for future growth in usage.