ACS Performance Guidelines

  • Article

Applies To

  • Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS)

  • Windows Identity Foundation (WIF)

Summary

This topic outlines key performance guidelines that you should take into account when you develop applications and services that use ACS. In particular the topic provides guidelines regarding token sizes and cryptography and how it affects overall performance.

Overview

In general, the key attributes of performance are response time, throughput, and resource utilization. For example, if the application has limited resources such as memory, chances are some information will hit the file system which is much slower than in-memory operations – this will affect overall response time. Here is another example, if the application sends a large amount of data over a network with limited bandwidth, it results in slower than desired response times. One approach to solve performance issues is to add more resources such as network bandwidth, faster CPU, and more memory. This approach may help although not always. Another approach is to improve code so that it uses fewer resources and exchanges less data. Considering the context of claims aware applications and what’s under developer’s control there are a few key factors related to using ACS that affect performance, namely, tokens and cryptographic operations related to the tokens.

Objectives

  • Define the aspects that affect performance in applications that use ACS.

  • Provide guidelines how to improve performance for each of the aspects.

Tokens Size And Encryption

Token size and encryption are key factors under the developer’s control that affect performance of applications integrated with ACS.

  • Token Size. Token size affects performance in two ways. First it directly affects performance related to network bandwidth to some degree. The larger the token the more network bandwidth it will take resulting in slower response overall. Second, the larger the token the more CPU cycles required to verify the integrity and extract claims in the token. Token processing includes parsing the token and de-serializing it into binary format so that your code can use it, the processing also includes several cryptography operations such as signature validation, and optionally decryption. The larger the token the more CPU cycles spent on its processing resulting in higher resource utilization and slower overall response. Token size depends on several factors: token format, cryptography applied to the token, and the claims in the token. ACS supports SAML, SWT, and JWT tokens. Generally a SWT or a JWTJWT token is smaller than a SAML token that carries equivalent amount of information. For more information read Token Formats Supported in ACS. There is caveat though, different token formats are optimized for different protocols and application architectures.

    • SWT Tokens are issued over WS-Federation, WS-Trust, and OAuth WRAP or OAuth 2.0 protocols. This means that SWT tokens can be used in Web applications, WCF (SOAP) services, and WCF (REST) services. WIF does not support the SWT token handler.

    • SAML Tokens are issued over WS-Trust and WS-Federation protocols. This means that SAML tokens can be used in Web applications and WCF (SOAP) services. WIF supports both SAML 2.0 and SAML 1.1 tokens. Read more about WIF in the following topic Windows Identity Foundation

    • JWT Tokens are issued over WS-Federation, WS-Trust, and OAuth 2.0 protocols. This means that SWT tokens can be used in Web applications, WCF (SOAP) services, and WCF (REST) services.

    One factor that contributes most to the token size is the claims contained in the token. The more claims the token carries the larger its size. In most cases claims that come with the token are under developer’s control. The claims used by an application are added, removed, or changed by the Security Token Service (STS) such as AD FS or ACS. ACS uses rule groups and rules to add, remove or change claims in a token. For more information read Rule Groups and Rules.

  • Encryption. Encryption and other cryptographic operations such as signing, signature validation, and decryption directly affect performance. Cryptography operations consume computation power due to the complex algorithms involved. ACS signs all tokens issued as an integrity measure to counter tampering attacks. Signature validation of tokens is not optional. Token encryption is required if a relying party application is a web service that is not using SSL to encrypt communications. WCF-based services using SOAP require encrypted, proof-of-possession tokens with the WS-Trust protocol. Token encryption is required to protect sensitive information over an unencrypted channel. However, in cases where the communication channel is encrypted, such as using SSL encryption, then using token encryption is optional and may not be applied in favor of improved performance.

See Also

Concepts

ACS Security Guidelines
Certificates and Keys Management Guidelines