Pål Axelsson wrote: > > If an attribute is case insensitive or not is up to the schema > definition.
Yes. But each schema definition of all application databases with user data (e.g. authz information) has to declare the user's ID as case-insensitive. Or better said: The equality matching when looking up user data in each database has to be case-insensitive. Therefore one also has to fix the application databases. > In RFC 4517 where uid is defined it clearly states that uid is case > insenstive so CAS should handle this out of the box. Strictly speaking the definition of LDAP matching rules in RFC 4517 only specifies how the LDAP server is supposed to perform the matching when searching for entries. That's not the problem of the original poster. > The easiest way is to return the uid instead of the user supplied > user id. Whatever that means in your setup. ;-) > This way it doesn't matter what the user supplies, it > returnes the correct value to the application. Note that while most LDAP servers implement a case-insensitive matching when searching entries the storage of attribute values is implemented in a case-respecting fashion without any normalization. Which means you could actually have mixed-case values for attribute 'uid'. And then you're back to the original problem. Don't mess equality matching for searching with storing normalized values. Ciao, Michael. _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
