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.

Thursday Sep 13, 2007

WS-Trust Implementation

OpenSSO (http://opensso.dev.java.net) now provides WS-Trust implementation for token exchanges.

Wednesday Sep 06, 2006

Securing Identity Web Services using NetBeans Enterprise Pack

In general securing web services involves establishing trust between the web service client (WSC) and the web service provider (WSP). And for services provided on behalf of a user (for example a calendar service), the WSP would have to trust the WSC to have authenticated the user, or the WSC would have to include the user's credentials (such as username/password, authentication assertions, etc.) as part of the web service request. Although this works good, it involves the business logic to insert this information and becomes difficult to modify later. Another option is to provide the user's credentials or tokens as part of the web service security headers, verified by WSPs termed as Identity Web Services. The distinguishing fact here is that Identity Web Services authenticates both web service clients as well as user identity.

Securing identity web services can be accomplished using any of the Web Service Security Basic Token Profiles (WS-I BSP) or using Liberty tokens. The key here is that the user's security token must be included in the web service security header by the WSC.

The newly released NetBeans Enterprise Pack 5.5 (currently in beta) has greatly simplified securing identity web services using Liberty tokens. The NetBeans tutorials explains the use of WS-I BSP security mechanisms for securing web services. However securing identity web services requires few additional steps (explained below) at the WSC after selecting "LibertyDiscoverySecurity" mechanism in the drop down menu. However for the WSP, the selection of either "Liberty Bearer Token" of "Liberty X509 Token" would suffice. BTW, I assume you have gone over the tutorial and are familiar with configuring the security mechanisms.

The issue at the WSC is that user must be authenticated so that WSC can send the user's security token to WSP. In order to authenticate the user, the deployment descriptors i.e., web.xml and sub-web.xml must be modified as follows. In web.xml, the following security constrains must be added to protect the WSC

    <security-constraint>
        <display-name>Access Manager Security Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>AUTHENTICATED_RESOURCE</web-resource-name>
            <url-pattern>/\*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>AUTHENTICATED_USERS</role-name>
        </auth-constraint>
    </security-constraint>

Additionally in sun-web.xml, we need to enable user authentication by providing a "Http" handler by replacing the following line:

    <sun-web-app error-url="">
with
    <sun-web-app error-url="" httpservlet-security-provider="AMHttpProvider">
Secondly, the security role mapping must also be provided after the definition for the <context-root>
  <security-role-mapping>
    <role-name>AUTHENTICATED_USERS</role-name>
    <principal-name>AUTHENTICATED_USERS</principal-name>
  <security-role-mapping>

After making the above changes and redeploying "Stock Client" and "Stock Service" would require the user to authenticate before accessing the WSC. The Access Manager bundled with NetBeans provide couple of sample users: jsmith and jondoe with passwords same as the user name. Analyzing the web service request would now show the user's identity being sent as part of the web service security headers.

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.

Friday Aug 18, 2006

NetBeans Enterprise Pack 5.5 Beta Released

The NetBeans Enterprise Pack 5.5 Beta is out today and can downloaded from Sun developer site or alternatively from NetBeans. This release has support for securing web services using WS-I BSP security mechanism such as SAML, X509 and Username tokens, and additionally using Libery Security mechanisms. Over the next few weeks, I plan to test this out and will be writing my findings, tips and tricks. So stay tuned.
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