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:
      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=false
      com.sun.identity.idm.cache.enabled=true or false
      com.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=true
      com.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=true
      com.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=true
      com.sun.identity.client.notification.url=<url>
The properties that enable notification for SMS are as follows:
      com.sun.identity.sm.notification.enabled=true
      com.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.

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

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.

Friday Jul 11, 2008

Configuring URL Connection timeouts in OpenSSO

OpenSSO server uses HTTP(S) to send change notifications to other servers and also to remote clients that have registered for changes. The implementation uses java.net.URLConnection, a common issue faced with it was the extraordinarily long read timeout when receiving end was not alive. Luckily J2SE 5.0 provides a solution by exposing a method setReadTimeout. OpenSSO uses this method to set the timeout and the configuration parameter that must be set correctly in OpenSSO: com.sun.identity.url.readTimeout This property could be set as an Advanced property in "Servers and Sites" Configuration tab and the value should be in milliseconds.

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:

-Dcom.iplanet.services.debug.level=message -Dcom.iplanet.services.debug.directory=c:/tmp/debug3

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

aravind

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today