|
|
Authorization caching allows the ASI Authorization and ASI Role Mapper providers to cache the result of an authorization call, and use that result if future calls are made by the same caller. The authorization cache automatically invalidates itself if there is a policy or user profile change. This section covers the following topics:
AquaLogic Enterprise Security also supports use of two other caches:
The entry keys for elements in the authorization cache are constructed from these elements:
The key construction algorithms are different for the authorization cache and the role mapping cache. The key-value pairs for entries in the authorization cache are:
Authorization: Map (key = Subject + Resource + Privilege + Roles + Contexts, value = Result + ResponseAttributes + Roles)
The key-value pairs for entries in the role mapping cache are:
Role mapping: Map (key = Subject + Resource + Contexts, value = Roles)
Note that Contexts and ResponseContexts can be single values or lists.
| Note: | ALES versions prior to 2.5 used a Pre Load Attributes configuration parameter. You may need to use this option if you use the latest version of ALES to manage ALES version 2.2 or 2.1 SSMs. For more details on using the Pre Load Attribute caching option see Authorization Caching in the ALES 2.2 documentation. |
Authorization performance of the ASI Authorization Provider can be improved further by setting the "Lazy Role Provider" switch (which can be found in the ALES Administration Console on the Performance tab of ASI Role Mapper Provider). If the switch is set, the authorization service will not make an extra call to acquire the list of roles that corresponds to a particular combination of subject, resource and context; instead, it will delegate this function to the ARME native process in a single call when a request for making the authorization decision is made.
The authorization cache is a per session object. This means that a separate cache object is created every time a client establishes the connection. If two Java-SSM clients have established connections, a separate cache object is created for each of them, even if the same credentials and SSM instance were used.
Authorization caching is on by default. It may be configured from within the Administration Console through the ASI Authorization and ASI Role Mapper provider configuration. Table 6-1 lists the switches affect the authorization cache.
|
Determines whether the provider loads ContextHandler data before starting to evaluate policy or waits for a callback to ask for specific items. Pre-loading attributes can dramatically improve performance in policies that use contextual attributes.
|
||||
When a request for list of roles is made, determines indicates whether a call should be made to the Role Mapping Cache / ARME or whether the call may be postponed until the returned list of roles is in fact used. Setting this true provides significant performance improvement when used in combination with the ASI Authorization provider since the provider can request the roles and the authorization decision in a single call.
|
The properties listed in Table 6-2 can be entered as advanced configuration properties to further tune the cache.
There is a small subset of data that may change without the knowledge of the cache. This includes internally computed time values, as well as custom evaluation plug-ins. Because the cache is not aware of changes in these values, it does not automatically invalidate a cached decision when they change. For this reason a series of evaluation functions is provided to control the period of cache validity. These functions are only needed in policies that make explicit use of internally computed time values or custom evaluation plug-ins.
Table 6-3 lists the internally computed time values. If these values are referenced in a policy, you should also explicitly set the cache validity for the policy.
Table 6-4 lists the expiration functions for the authorization cache. You can use these functions to set an expiration time for the decision. This way you can instruct the cache to only hold the value for a given period of time, or to not hold it at all. These functions correspond roughly to each of the internally computed time types.
For example, if you had the following policy:
GRANT(//priv/order,//app/resturant/breakfast,//sgrp/customers/allusers/) if hour < 11;
When authorization caching is enabled, you write the policy as:
GRANT(//priv/order,//app/resturant/breakfast,//sgrp/customers/allusers/) if hour < 11 and valid_until_hour(11);
With authorization caching, the result of this policy is cached in the provider until 11:00 AM, at which time, it expires. Not calling valid_until_hour argument results in this policy being cached until the next policy distribution. Therefore, if you are using authorization caching, it is important to update your time dependent policies appropriately.
|