Bug 35603 - JNDIPrincipalStore needs to ignore case when checking 'groupMemberSet' attribute
Summary: JNDIPrincipalStore needs to ignore case when checking 'groupMemberSet' attribute
Alias: None
Product: Slide
Classification: Unclassified
Component: Stores (show other bugs)
Version: Nightly
Hardware: All other
: P2 normal (vote)
Target Milestone: ---
Assignee: Slide Developer List
Depends on:
Reported: 2005-07-05 06:33 UTC by Jojada
Modified: 2005-07-10 23:31 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Jojada 2005-07-05 06:33:28 UTC
In the JNDIPrincipalStore's getRevisionDescriptior(URI) method there is a line 
that checks an attribute name against 'groupMemberSet' field:
boolean isGms = attribute.getID().equals(groupMemberSet);
Shouldn't this call equalsIgnoreCase() instead ?
Comment 1 James Mason 2005-07-07 19:45:51 UTC
Since the value of groupMemberSet is configurable, this shouldn't be a problem.
Do you have a situation where the casing of the attribute name varies between
objects? I don't believe that's possible, but I could be wrong.
Comment 2 Jojada 2005-07-11 02:33:35 UTC
No, that's not the situation I have or am looking at. I came across this issue 
after spending hours in configuring JNDIPrincipalStore and trying to find out 
why the configuration was not working. I could have saved my time if 
the 'groupMemberSet' attribute value was case-insensitive as other attributes. 
Besides, I think it's been a common practice if not a requirement that an LDAP 
attribute name is case-insensitive. By the way, thanks for the 
JNDIPrincipalStore code, it is great! 
Comment 3 James Mason 2005-07-11 05:57:08 UTC
Thanks for the compliment :).

I'm a little wary of hard-coding case-insensitivity, since I don't know enough
about the LDAP specs to know what problems that could lead to. Since this was
prompted by problems you had getting a configuration working, maybe there's a
different solution that would help others pinpoint the problem?

Could the documentation be improved, or maybe some changes to the logging to
warn about possible problems?
Comment 4 Carlos Villegas 2005-07-11 06:29:56 UTC
If I remember correctly, the way attributes are compared within an LDAP server 
is defined by the LDAP schema (type) of the object. There are case insensitive 
types like names but also case sensitive and ways to compare binary strings. A 
solution would be to read this information from the LDAP server itself, which 
is possible. Another solution would be to add a configuration option to 
indicate case sensitivity of the attributes.
Comment 5 Jojada 2005-07-11 07:31:55 UTC
When we compare the *value* of an attribute then we pay attention to 
description defined in the schema. There are caseIgnoreMatch, octetStringMatch, 
etc. However, the jndi.attributes.groupmemberset parameter defines an attribute 
*name/type* and an LDAP attribute name/type is case-insensitive as mentioned in 
the following refereces:
1. http://java.sun.com/products/jndi/tutorial/ldap/misc/attrs.html.
2. LDAP Programming with Java, p.31, by R.Weltman and T.Dahbura, Addison Wesley 
Longman Inc., 2000.
3. RFC2252 p.13.