Programming Security for Web Services
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
You can use a client-side Authorization cache to allow an application using the Web Services SSM to take advantage of in-process caching to achieve performance improvements when making authorization calls.
The Web Services Authorization cache has been implemented as an Axis handler. The handler implementation allows you to add and remove the Authorization cache without affecting existing code. The Authorization cache can be configured through a Java API. If you do not use the configuration API to configure the cache, the default values for the cache will be used.
The Authorization cache is provided as a separate Java Library (JAR file), ssmwsClientCache.jar
. This JAR file, as well as the cacheclientconfig.wsdd
file, must both be available to your Web Services client application in order for the cache to function. The ssmwsClientCache.jar
is installed by default in:
BEA_HOME
/ales21-ssm/webservice-ssm/lib
You can enable the cache in your Web Services client application in one of two ways:
As an alternative, you can enable the cache programmatically. At the beginning of the Web Services client program before any Axis call, set the Axis properties for the cacheclientconfig.wsdd
. For example:
AxisProperties.setProperty("axis.ClientConfigFile", D:/ssmws/axis/config/cacheclientconfig.wsdd");
The Web Services client Authorization cache requires a third party product, Apache Axis 1.2.1, which is a Java implementation of SOAP. The following elements of Axis are required:
axis.jar
axis-ant.jar
commons-discovery-0.2.jar
commons-logging-1.0.4.jar
jaxrpc.jar
saaj.jar
wsdl4j-1.5.1.jar
For more information about downloading and using Axis, see the Apache Software Foundation's Axis site.
The authorization method, isAccessAllowed()
, has five parameters:
The first four parameters and Direction act as the keys in the Authorization cache's entries. The keys in the Authorization cache are constructed using the following formula:
If the Request Credential Type parameter is set, the return result may have a new IdentityAssertion
. In this case, the cache will be bypassed, and the cache is updated accordingly if a new IdentityAssertion
is returned.
The value in the cache holds all the contents of the response, including access decision, response attributes, and roles, if any.
As described in Config on page 2-4, the Authorization cache's behavior is configurable, using the Config
class. The Authorization cache will be updated if one of following criteria is met:
SessionExpirationDuration
expires. The expired entry will be removed. The client will call isAccessAllowed
and establish a new session for this IdentityAssertion
. SessionExpirationDuration is a system attribute that you can configure using the Config
class. Set this attribute to a time that is short enough that the policy changes will not affect the correctness of the caching results.IdentityAssertion
is returned when calling isAccessAllowed
. The client will remove all cached evaluation decisions on this IdentityAssertion
.Config.sessionEvictionCapacity
). A configurable percentage (Config.sessionEvictionPercentage
) of least-recently-used sessions will be removed.Config.userEvictionCapacity
). A configurable percentage (Config.userEvictionPercentage
) of least-recently-used cached values will be removed.CacheManager.flush()
is called, the whole cache will be flushed.There will be only one Authorization cache in any one Web Services client application. The cache is used only for the authorization call to one Web Services SSM.
In addition to the public API provided by the Web Services SSM (see Web Services Interface in Programming Security for Web Services), the Web Services Client Authorization Cache provides a configuration API so that you can customize the Authorization cache implementation. The following classes are packaged in com.bea.security.ssmws.client
:
The optimal values to use in configuring the cache depend on your application's particular needs and traffic. The maximum number of entries in the cache is the product of the SessionEvictionCapacity
and the UserEvictionCapacity
. Make sure that the maximum size of the cache does not exceed the amount of memory that you can allocate for the cache. In production, monitoring the CacheManager's HitRatio
will indicate how effectively the cache is being used.
The com.bea.security.ssmws.client.Config
class provides these methods for configuring the Authorization cache:
public void setSessionExpirationDuration(int sessionExpirationDuration)
Set the duration for which to cache session data, in seconds. Default value is 60.
public void setSessionEvictionCapacity(int sessionEvictionCapacity)
Set the number of authorization sessions to maintain in the cache. Once the limit is reached, old sessions are dropped and automatically re-established when needed. Default value is 1000.
public void setSessionEvictionPercentage(float sessionEvictionPercentage)
Set the percentage of authorization sessions to drop when the eviction capacity is reached. Default value is 10.
public void setUserEvictionCapacity(int UserEvictionCapacity)
Set the maximum number of users who can have sessions in cache simultaneously. Once exceeded, old cached values are overwritten. Default value is 500.
The com.bea.security.ssmws.client.CacheManager
class provides these methods for configuring and operating the Authorization cache:
![]() ![]() |
![]() |
![]() |