|
|
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.
The context element above may be different from the one that is supplied during authorization call by the client. Context attributes can be supplied to the ARME in one of two different ways, depending on the value of the "Pre Load Attributes" configuration parameter. The "Pre Load Attributes" configuration parameter determines whether the provider preloads the context with all data (including attributes) before starting to evaluate policy or waits for a callback to ask for specific items.
If the "Pre Load Attributes" parameter is assigned the value all, then all context attributes will be passed to the ARME even if some of them are not used in the authorization decision-making process. This approach has the advantage of avoiding callback calls from the ARME asking for missing attributes. However, it may increase overhead of inter-process communication, because all available attributes are passed to the ARME whether they are needed or not. In addition, the keys in the authorization cache may have substantially greater size.
If the "Pre Load Attributes" parameter is assigned one of the values none, adaptive-private (the default) or adaptive-shared, the context contains only the attributes necessary to make the authorization decision. If during an authorization call an entry cannot be found in the cache, the call is delegated to the native ARME process that provides through callbacks the list of attributes required to make the authorization decision. If the call was successfully executed, the caching logic stores the list of attributes participated in the decision process; therefore, the next time the same call is made, the provider will know which context attributes should be used in search for the cached result. Internally the required attributes list is stored under corresponding value of resource-privilege pair. This approach has the following advantages:
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 14-1 lists the switches affect the authorization cache.
The properties listed in Table 14-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 14-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 14-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.
|