|
|
You can improve OES’s authorization performance in Web Services application using one or more caches. The following caches are available:
The client-side authorization cache and the server-side identity cache are described in the following sections:
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/ales32-ssm/webservice-ssm/libTo enable the cache in your Web Services client application:
As an alternative, you can enable the cache programmatically by setting the Axis properties for the cacheclientconfig.wsdd at the beginning of the Web Services client program before any Axis call. For example:
AxisProperties.setProperty("axis.ClientConfigFile", D:/ssmws/axis/config/cacheclientconfig.wsdd");Listing 3-1 gives an example of the cacheclientconfig.wsdd file.
<?xml version="1.0" encoding="UTF-8"?>
<deployment name="defaultClientConfig"
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<globalConfiguration>
<parameter name="disablePrettyXML" value="true"/>
<requestFlow>
<handler type="java:com.bea.security.ssmws.client.CacheRequestHandler"/>
</requestFlow>
<responseFlow>
<handler type="java:com.bea.security.ssmws.client.CacheResponseHandler"/>
</responseFlow>
</globalConfiguration>
<transport name="http" pivot="java:org.apache.axis.transport.http.HTTPSender"/>
<transport name="local" pivot="java:org.apache.axis.transport.local.LocalSender"/>
<transport name="java" pivot="java:org.apache.axis.transport.java.JavaSender"/>
</deployment>
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:
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:
IdentityAssertion + Resource + Action + Contexts + Direction, value = Result + ResponseAttributes + Roles)
Note that the context object is actually an array of context record elements. Two arrays are considered equal if they contain the same elements in the same order. Consequently, two context objects are considered unequal if the context record elements they consist of were added in a different order.
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 (single values and lists), and roles, if any.
As described in
Config on page 3-5, 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.
Please note that configuration parameters of the server-side authorization cache have no effect on the client-side authorization cache. These caches are completely independent and do not share any configuration.
The com.bea.security.ssmws.client.Config class provides these methods for configuring the Authorization cache:
The com.bea.security.ssmws.client.CacheManager class provides these methods for configuring and operating the Authorization cache:
Config object. This method can be called one time. If any other call occur before this, an implicit initialization is done. Once initialized, subsequent calls to initialize are ignored.
You can improve the performance of Web Services applilcations by enabling and configuring the Web Services SSM’s server-side identity cache.
Every isAccessAllowed operation called by the client requires a valid identity (subject, roles, custom profile data, etc). However, the client stores only a token that can be used to create a valid identity on the server side. Identity creation is a relatively expensive operation that can consume substantial amount of resources and time. To avoid this overhead, you can configure the Web Services SSM to cache the identities; thus, when the server gets a request, it will try to find the identity object in the cache instead of creating a new one.
You configure the Web Services SSM identity cache in the <cache> element of <INSTANCE_HOME>/apps/ssmws-asi/SAR-INF/config.xml, where <INSTANCE_HOME> is the installation directory of the Web Services SSM instance. Listing 3-2 shows a fragment from this configuration file.
<cache>
<!-- This setting enables/disables server-side identity caching. Values: true/false. Optional -->
<enabled>true</enabled>
<!-- TTLs for server-side caching of user identities, seconds. Names: any acceptable credential type. Optional -->
<tokenTTLs>
<SAML.Assertion>300</SAML.Assertion>
<ALESIdentityAssertion>300</ALESIdentityAssertion>
</tokenTTLs>
</cache>
The <cache> element contains two parameters that configure the identity cache:
You should configure the identity cache based on your requirements, available hardware, application usage patterns, etc. However, if the Web Services SSM is used to secure an application that has a concept of session timeout itself, for example, a web application or a portal application, then you should set the timeout value of the identity cache to a value similar to the one that is used in the application. In that case, the identity object will be removed as soon as the application session has been expired, and, on the other hand, no additional re-authentication will be required while the session is active.
|