ACS Service Limitations
Updated: June 19, 2015
Applies To: Azure
This topic explains the maximum values that Microsoft Azure Active Directory Access Control (also known as Access Control Service or ACS) allows for different aspects of the service.
Google Identity Provider Support
ACS namespaces can migrate their Google identity provider configurations from OpenID 2.0 to OpenID Connect. Migration must be completed before June 1, 2015. For detailed guidance, see Migrating ACS Namespaces to Google OpenID Connect.
Rules Executed Eight Times per Input Token
Whenever ACS receives an input token for a relying party application, the ACS rules engine executes all rules associated with that relying party application simultaneously. If the rules output additional claims not present in the input token, then all rules are executed again with those claims as the input values. Rule execution stops when no new claims are issued after an execution completes, or eight executions have completed (whichever comes first).
Management Service Limits Query Results
When using the Management Service to query rule groups for rules, the service limits the query result to no more than 100 rules. This is because the Management Service uses the Open Data (OData) protocol and returning 100 objects at a time (paging) is standard behavior for OData endpoints.
The result size for each of the ACS entities is as follows:
Rules: 100
Everything else: 50
Larger result sets can only be handled by implementing paging in your Management Service client code. For pagination examples, see How to: Load Paged Results (WCF Data Services) (https://go.microsoft.com/fwlink/?LinkID=193452).
Incoming Claims Limit
In order for the ACS to process and successfully issue a security token, the number of claims in the incoming token must be equal to or no greater than 80. If the number of the incoming claims is greater than 80, the following error message is generated: The number of input claims (#) exceeds the limit (80).
Token Request Rate Limit
To improve ACS availability and performance for all users, ACS has implemented a sustained rate limit of 30 token requests per second for each namespace. This per-namespace rate limit is measured as an average for each minute over several minutes, so it is not triggered by infrequent spikes. If a token request rate of more than 30 requests per second continues for a prolonged period, ACS rejects excess token requests from the namespace for the duration of the interval and returns an HTTP 429 "Too many requests" error with the ACS90055 error code.
ACS also rejects token requests when ACS resources are temporarily consumed by a high token request rate from all namespaces. In this case, ACS returns an HTTP 503 "Service unavailable" error with the ACS90046 (ACS busy) or ACS60021 (data server busy) error codes.
When you get HTTP 429 or 503 errors, retry the requests with a back-off timer, as discussed in ACS Retry Guidelines. If the retries are not distributed over increasing time intervals, the accumulated retries are likely to exacerbate the problem and prolong the period during which token requests are rejected. If you are getting recurring ACS90055-HTTP 429 errors because your namespace is exceeding the token request rate limit, consider redistributing your workload by replacing a single namespace with several smaller namespaces.