Oracle Blog

On Identity and Security

Caching in OpenSSO

Of the various components in OpenSSO, the two main components that heavily relies on caching for performance and better user experience are Services Configuration data (aka SMS) and Identity Repository (aka IdRepo). This blog attempts to provider details on the parameters/properties that controls its size and time to refresh (or to be removed from cache).

First, properties that enables the cache:
Enabling both the caches is controlled by the property:com.iplanet.am.sdk.caching.enabled and is set to true by default. Hence unless you want to disable one or both of the caches, this property need not by modified.
To disable both the caches:com.iplanet.am.sdk.caching.enabled=false

The property that controls IdRepo cache is com.sun.identity.idm.cache.enabled and the property that controls SMS cache is com.sun.identity.sm.cache.enabled. Hence to enable one or the other cache, the following properties needs to be added:com.iplanet.am.sdk.caching.enabled=falsecom.sun.identity.idm.cache.enabled=true or falsecom.sun.identity.sm.cache.enabled=true or false

Of the 2 caches, only the cache size of IdRepo can be limited and is controlled by the property:com.iplanet.am.sdk.cache.maxSize
and is set to 10000 entries by default.

Next, the manner in which the entries in the cache get dirtied depends on its environment i.e., as OpenSSO server or within an application using openssoclientsdk.jar and AMConfig.properties. In either scenario, one common mechanism to invalidate an entry in the cache is time-to-live (aka TTL). The properties that enable TTL for IdRepo are as follows:com.sun.identity.idm.cache.entry.expire.enabled=truecom.sun.identity.idm.cache.entry.default.expire.time=1 (in minutes).
The properties that enable TTL for SMS are as follows:com.sun.identity.sm.cache.ttl.enable=truecom.sun.identity.sm.cache.ttl=30 (in minutes).

Client Properties
For clients using openssoclientsdk.jar and AMConfig.properties, there are couple of mechanisms to invalidate entries in the cache. The first is by setting up a notification URL that OpenSSO server can send change notifications to the clients. The works for web application and standalone applications that can listen on port for Http(s) traffic. However, this mechanism also has the drawback that there could be a constant flooding of notification changes especially for user attribute changes that it could overwhelm the clients. The second mechanism (works only if notification is disabled) is polling, where the client periodically polls the OpenSSO server for changes.
The properties that enable notification for IdRepo are as follows:com.sun.identity.idm.remote.notification.enabled=truecom.sun.identity.client.notification.url=<url>
The properties that enable notification for SMS are as follows:com.sun.identity.sm.notification.enabled=truecom.sun.identity.client.notification.url=<url>
Details on setting up the notification service URL can be found here

The property that enable polling for IdRepo (only if notification is disabled) is:com.iplanet.am.sdk.remote.pollingTime=1 (in minutes)

The property that enable polling for SMS (only if notification is disabled) is:com.sun.identity.sm.cacheTime=10

It is always good to play with different combination of these options for optimal performance and user experience. There is no one option that satisfy all scenarios.

Server Properties
With respect to Identity Repository, there are couple of ways in which the cache can be invalidated. Both can be enabled simultaneously, and is the recommended option.

Time-to-live configuration mentioned above

Change notifications send by data stores. Here the individual data stores configured in IdRepo must listen to changes in their respective backends and send notifications. In the case of directory server, the persistent search notifications should be enabled.

Similarly for SMS also, its cache can be invalidated by the TTL configuration mentioned above and also by optionally setting the persistent search notifications to the directory server which holds the configuration data. Unlike the IdRepo where user attributes could be changed by other products, it is assumed that services configuration data would be modified only via the OpenSSO server or via the ssoadm CLI. In such scenarios it is perfectly fine not to establish persistent search connections to configuration store. OpenSSO internal has the logic to propagate the changes to other servers in a multi-instance environment.
During configuration of the OpenSSO if Embedded DS is chosen as the configuration store, persistent searches are not setup. However if an external directory server is chosen, then persistent searches are enabled.

The property that enables persistent search connections for SMS is:com.sun.identity.sm.enableDataStoreNotification=true
and can be modified via console by navigating to:Configuration --> Servers and Sites --> <server-url> --> SDK --> Enable Data Store Notification
Additionally, the following property must be modified to remove sm from its list:
com.sun.am.event.connection.disable.list
This property can also be modified via console by navigating as mentioned above.

For the OpenSSO server, the recommendation would be to enable TTL for both IdRepo and SMS in addition to persistent searches. This is to handle the scenario where a network glitch might have caused the OpenSSO server to miss some change notifications. The value of TTL purely depends on the deployment environment and user experience.