Explained: ibm-allGroups, security cache timeout
 Technote (troubleshooting)
 
Problem(Abstract)

Performance to retrieve users from LDAP server can be improved using ibm-allGroups parameter. It is also important to understand the settings for security cache timeout as it is related to refresh interval for the security cache.
 
Resolving the problem
Certain directory servers like IBM® Tivoli Directory Server allow client to directly query user's group membership from user entry's attributes. The group membership is an operational attribute, and it is available on demand. In IBM directory server, a group membership lookup could be done by searching the ibm-allGroups attribute for the user entry. When client provides a valid LTPA token, WebSphere® Application Server will make 3 LDAP calls to map the Token to a validated security subject, however, the 3 LDAP calls can be reduced to 1 by using ibm-allGroups parameter. Significant performance improvements were noticed on the LDAP server with ibm-allGroups parameter setting in WebSphere Application Server..

This parameter can be set on WebSphere Application Server admin console:
Security > User Registries > LDAP Advanced LDAP settings. On the LDAP settings panel change the Group Member ID Map setting to the following value: ibm-allGroups:member;ibm-allGroups:uniqueMember

Security Cache Timeout:
The size of the security cache is related to the credential/subject A credential is an internal representation of a validated user. Credential size can significantly increase if a user belongs to many groups. So it is not desirable to have too many groups for a member.
Security authentication cache can reduce and delay calls to directory servers and thus provide performance improvements. The security cache timeout value specifies how long an inactive security credential stays in the security cache. The security cache timeout value is relative to the last active time of the credential. The timeout setting specifies how often to refresh the security-related caches. The credential is refreshed and a new one is created once the credential is close to security cache timeout value and at that time a call to LDAP will be made.

This parameter can be set on WAS admin console:
Security->Global security->cache timeout

Credential:

A credential is an internal representation of a validated user, and it contains at least following attributes:

realmname (like wasLDAP.ibm.com:636);
username (like testUser)
uniqueusername (like uid=testuser,dc=austin,dc=ibm,dc=com)
primaryGroupId (like group:wasLDAP.ibm.com:636/cn=my primary group,dc=austin,dc=ibm,dc=com)
accessId (user:wasLDAP.ibm.com:636/uid=testuser,dc=austin,dc=ibm,dc=com)
credential Tokens
expirationTime
All groupIds (list all groups a user belongs to, and realm is appended to each group)


Cache keys include:
realm:user
realm:uniqueSecurityName
LTPA token
realm:loginName
additional keys.

A credential lives in security cache no less than security cache timeout value, and no more than 1.5* security cache timeout value. For example, if the security cache size for one user is C, and total concurrent users are T, the cache size is about (1 + 1.5)/2*C*T = 1.25*C*T. Security cache timeout calculation is different from LTPA expiration, while LTPA token expiration is not reset once it is time stamped, the security cache timeout is reset when it is referenced. So security cache timeout is the timeout since last referenced.

Question:
What are the consequences on the memory of WebSphere Application Server if a user is in many groups for example 500 groups? What is considered a large group?
Answer:
User's group memberships are included in user's credential. If a user belongs to too many groups, credential size will be increased significantly, as a result, the credential cache size becomes big. We suggest to limit the number of groups a user belongs to.

Question:
What are the consequences of setting the security cache from 10 minutes to 1 hour?
Answer:
10 minutes are considered the minimal timeout. A good starting point for security cache timeout value is 10 minutes, however this can vary based on client requirements. Cache timeout too small will force credential removed too often, and may refresh credential many times even before a user session is completed. Too large cache timeout will result in too many users in cache, and consume too much memory. User has to make a compromise, and choose a proper value that fits their environment.

Question:
How does the cache get flushed? Is it by entry? When?
Answer:
Credential cache could be flushed out in two ways. One is when it is accessed, and
credential is expired. If a user access an expired or about to be expired credential, the credential would be removed from cache. We also have a background monitor to remove credential out of cache if the credential is not referenced in certain time period, which is greater than security cache timeout value but less than 1.5* security cache timeout value.

Question:
When a new LTPAToken is created (and added to the cache), does this imply that the credential (WSCredential in the cache) is recreated (or updated, especially the expiration attribute)?
Answer:
If logging in with a new token (i.e., the token is not exactly the same old token), a new credential would be created.

Question:
What are the relations between cache time-out and the other time-out?
Answer:
Security Cache timeout value determines how long a credential will live in cache if it is not referenced directly. The other security related timeout is LTPA Token expiration time. The ltpa expiration specifies how long a token is validated since it is created. Generally, we recommend LTPA expiration time greater than 2*security cache timeout value. If a credential is in cache and its ltpa token is expired, and if a user accesses this credential, this credential would be removed first, then user will be asked to re-authenticate itself.
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Security
Operating system(s): Windows
Software version: 6.0
Software edition:
Reference #: 1240176
IBM Group: Software Group
Modified date: Jun 26, 2006