Performance

  • Article

Applies To: Windows Server 2003 with SP1

Application initialization and access validation performance can vary, depending on how applications use features such as XML storage, BizRules, and LDAP query groups. Application designers have several options to consider in meeting performance requirements.

Application initialization performance

Load times for large stores improve when you use the Active Directory store rather than the XML Authorization Manager storage provider. When an application initializes a connection to an Authorization Manager policy store, authorization policy is loaded into the address space of the application. The amount of policy that is loaded depends on the store type.

  • The Active Directory Authorization Manager policy store allows Authorization Manager application objects to be loaded and unloaded on demand and allows the Authorization Manager scope objects to be loaded only when needed. (For more information, see Active Directory Authorization Manager Storage, earlier in this paper.)

  • The XML Authorization Manager storage provider loads the entire authorization policy into memory.

Additionally, the time it takes to initialize increases as the number of objects within the Authorization Manager policy store increases or as the number of members in Authorization Manager application basic groups increases. To minimize the size of application groups, use Active Directory groups when possible and then use these Active Directory groups in Authorization Manager application groups or roles.

AccessCheck performance

Using the Authorization Manager AccessCheck method provides a flexible way to optimize performance using BizRules and LDAP query groups.

The AccessCheck method:

  1. Identifies scopes that apply to the AccessCheck routine, both within the specified scope and the global scope.

  2. Enumerates the set of roles in the scopes from step 1.

  3. Discards roles that do not refer to requested operations. If RoleForAccessCheck is specified, all roles other than those specified are discarded.

  4. Verifies the client security contexts membership in each role.

  5. If the client is a member of the role in step 4, AccessCheck records all requested operations that are assigned to the role as granted.

  6. Repeats steps 3-5 for each role in applying scopes.

The above logic is repeated a maximum of three times.

  1. On the first pass, AccessCheck ignores any tasks containing BizRules and application groups containing LDAP queries. Both BizRules and LDAP queries can take a long time to compute and can require network operations, so the first pass takes place in case they are not needed.

  2. In the second pass, AccessCheck processes BizRules, but still ignores LDAP query groups. BizRules are supposed to be simple and may not involve network operations, so they are likely to be faster to process than LDAP queries.

  3. The third pass processes all data, including LDAP queries, using the cached results from previous iterations. AccessCheck terminates as soon as access is granted to all of the requested operations.

Since AccessCheck is optimized to evaluate static memberships ahead of dynamic memberships, and tasks without BizRules ahead of tasks with BizRules, you can optimize performance by using static assignments where possible.

Authorization Manager application groups are not evaluated until AccessCheck is called and membership in a role is queried. (This process of group evaluation is also called late-bound.) For LDAP query application groups, once membership in an application group is established for a user, the users membership in that LDAP query group is cached for the life of the user context object. Because of this, future AccessChecks that involve group evaluations speed up as group memberships are resolved and cached.

As a best practice, BizRules should be kept computationally small. BizRules offer the greatest degree of flexibility in an AccessCheck call, and therefore offer the greatest potential to decrease performance. Network bound BizRules decrease the performance of AccessCheck. Often, this cannot be avoided, for example, if a database needs to be queried to check a credit history, but such queries will delay the result to the user.