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