Policy Managers Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Authorization Caching

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:

 


Authorization Cache Operation

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 this product 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 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.

 


Configuring Authorization Caching

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 7-1 lists the switches affect the authorization cache.

Table 7-1 Authorization Caching 
Setting
Default Value
Description
AccessAllowedCaching
true
Enables/disables caching of authorization decisions.
GetRolesCaching
true
Enables/disables caching of role mapping decisions.
SessionExpiration
60
Specifies the number of seconds that authorization decisions for a user will be cached in memory. Upon expiration, the cached information is cleared and then updated if the user makes a subsequent request.
While increasing this value can improve performance, it may also reduce security by making authorization decisions based on outdated information.
SubjectDataCacheExpiration
60
Defines how long user profile data will be cached. Cached authorization decisions are reset each time this data cache expires. You can increase this value to improve performance.
Pre Load Attributes
adaptive-private
Not used as of ALES version 2.5.
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.

Note: ALES versions prior to 2.5 used the Pre Load Attributes configuration parameter. You may need to use this option if you use the latest version of OES 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.

Lazy Role Provider
true
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 7-2 can be entered as advanced configuration properties to further tune the cache.

Table 7-2 Advanced Configuration Properties 
Setting
Default Value
Description
ASI.AuthorizationCacheLimit
1000
Determines the maximum number of cached decisions per user session. Once exceeded, old cached values are overwritten.
ASI.AuthorizationCacheDynamicAttributeLimit
10
Determines the maximum number of context attributes a decision may use and still be stored in the cache.
ASI.PolicyCacheInvalidatorPollingInterval
1000
Determines how often the cache checks for policy distributions. The value is in milliseconds

 


Authorization Caching Expiration Functions

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 7-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 7-3 Time Values Used with Expiration Functions 
Credential
Value
Range or Format
time24
integer
0– 2359
time24gmt
integer
0– 2359
dayofweek
Dayofweek_type
sunday– saturday
dayofweekgmt
Dayofweek_type
sunday– saturday
dayofmonth
integer
1– 31
dayofmonthgmt
integer
1– 31
dayofyear
integer
1– 366
dayofyeargmt
integer
1– 366
daysinmonth
integer
28– 31
daysinyear
integer
365– 366
minute
integer
0– 59
minutegmt
integer
0– 59
month
month_type
january– december
monthgmt
month_type
january– december
year
integer
0– 9999
yeargmt
integer
0– 9999
timeofday
time
HH:MMAM” or “HH:MMPM”
timeofdaygmt
time
HH:MMAM” or “HH:MMPM”
hour
integer
0– 23
hourgmt
integer
0– 23
date
Date
MM/DD/YYYY”
dategmt
Date
MM/DD/YYYY”

Table 7-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.

Table 7-4 Expiration Functions 
Function
Argument
Description
valid_for_mseconds
integer
Valid for a given number of milliseconds
valid_for_seconds
integer
Valid for a given number of seconds
valid_for_minutes
integer
Valid for a given number of minutes
valid_for_hours
integer
Valid for a given number of hours
valid_until_timeofday
time
Valid until the specified time on the date the evaluation is performed
valid_until_time24
integer
Valid until the specified time on the date the evaluation is performed
valid_until_hour
integer
Valid until the specified hour on the date the evaluation is performed
valid_until_minute
integer
Valid until the specified minute of the hour the evaluation is performed
valid_until_date
Date
Valid until the specified date
valid_until_year
integer
Valid until the specified year
valid_until_month
month_type
Valid until the specified month of the year the evaluation is performed
valid_until_dayofyear
integer
Valid until the specified day of the year the evaluation is performed
valid_until_dayofmonth
integer
Valid until the specified day of the month the evaluation is performed
valid_until_dayofweek
Dayofweek_type
Valid until the specified day of the week the evaluation is performed
valid_until_timeofday_gmt
time
Valid until the specified time on the date the evaluation is performed in GMT time.
valid_until_time24_gmt
integer
Valid until the specified time on the date the evaluation is performed in GMT time.
valid_until_hour_gmt
integer
Valid until the specified minute of the hour the evaluation is performed in GMT time
valid_until_minute_gmt
integer
Valid until the specified minute of the hour the evaluation is performed in GMT time.
valid_until_date_gmt
Date
Valid until the specified date in GMT time.
valid_until_year_gmt
integer
Valid until the specified year in GMT time.
valid_until_month_gmt
month_type
Valid until the specified month of the year the evaluation is performed in GMT time.
valid_until_dayofyear_gmt
integer
Valid until the specified day of the year the evaluation is performed in GMT time.
valid_until_dayofmonth_gmt
integer
Valid until the specified day of the month the evaluation is performed in GMT time.
valid_until_dayofweek_gmt
Dayofweek_type
Valid until the specified day of the week the evaluation is performed in GMT time.

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.


  Back to Top       Previous  Next