Wednesday Nov 05, 2008

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:
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:

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

Of the 2 caches, only the cache size of IdRepo can be limited and is controlled by the property:
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 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.default.expire.time=1 (in minutes).
The properties that enable TTL for SMS are as follows: (in minutes).

Client Properties
For clients using openssoclientsdk.jar and, 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:
The properties that enable notification for SMS are as follows:
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: (in minutes)

The property that enable polling for SMS (only if notification is disabled) is:

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.

  1. Time-to-live configuration mentioned above
  2. 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:
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:
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.

Wednesday Jul 23, 2008

OpenSSO Express Support

With the announcement of OpenSSO Express Support, it is now possible to get support for the selected builds of OpenSSO. Details of the supports and FAQs are available at the OpenSSO wiki.

Wednesday Jul 09, 2008

Enabling debugs in OpenSSO during install time

In OpenSSO it has been difficult to enable debug messages during install time. One easy way to enable message is to add the following 2 properties to the container's JVM property setting:

In the above example, debug has been set to "message" level and the debug files would be created in "c:\\tmp\\debug3". Restart the container and all debug message would be written to this directory.

Friday Jun 13, 2008

Identity Services

Enhancements have been to done to Identity Services offered by OpenSSO. It now provide more support for user management, mainly CRUD operations. More details at the SDN article.

Saturday Aug 19, 2006

Access Manager 7.1 Beta web archive (war)

The release of NetBeans Enterprise Pack 5.5 Beta includes the web archive (war file) of Access Manager 7.1 Beta. The war file is placed within Sun Application Server's install directory under "addons/amserver" as "amserver.war". By default NetBeans installation deploys the war file within the Application Server under the URI "/amserver".

However the war file can deployed in other servlet containers. Once deployed within the servlet container, the first access to the web application provides a very simple configuration page. Configuration takes less than a minute and Access Manager is ready for use.

The directory to store the Access Manager's configurations is the most important parameter. After installation this directory can be backed up as needed to recover back to a know state. BTW, this assumes that the data store used to manage identities is "files".

Instructions to uninstall Access Manager can be found in NetBeans Trouble shooting guide under "NoClassDefFoundError: cannot access amserver occurs during installation". Basically the steps are to undeploy the web application and to remove the configuration directory. Additionally, Access Manager maintains a bootstrap file $HOME\\AMConfig_server_amserver_, the last component being the deploy URI. This file must also be deleted. However before redeploying Access Manager, the servlet container must be restarted to clear the initialized static variables.




« April 2014