Open Stack

On Wed, Sep 25, 2013 at 09:45:32AM +0100, Henry Nash wrote:
> Hi
> 
> Do we specify somewhere whether text field matching in the API is case
> sensitive or in-sensitive?  I'm thinking about filters, as well as user and
> domain names in authentication.  I think our current implementation will
> always be case sensitive for filters  (since we do that in python and do not,
> yet, pass the filters to the backends), while authentication will reflect the
> "case sensitivity or lack thereof" of the underlying database.  I believe
> that MySQL is case in-sensitive by default, while Postgres, sqllite and
> others are case-sensitive by default. 
> If using an LDAP backend, then I think this is case-sensitive.
That heavily depends on which LDAP Attributes you use. The usual suspects user
for authentication: "uid", "cn" and keystone's default "sn" are all defined to
be case-insensitive.
 
> The above seems to be inconsistent.  It might become even more so when we
> pass the filters to the backend.  Given that other projects already pass
> filters to the backend, we may also have inter-project inconsistencies that
> bleed through to the user experience.  Should we make at least a
> recommendation that the backend should case-sensitive (you can configure
> MySQL to be so)?  Insist on it? Ignore it and keep things as they are?
For LDAP it will be pretty hard to enforce any particular matching. Especially
if we want to support people using their existing LDAP servers as a backend for
keystone. You could of course enforce this on the LDAP client side (i.e. inside
keystone's LDAP backend), but I am not sure if that is really a good idea. It
might have a negative impact once filtering is implemented in the LDAP backend.

As Dolph already suggested we should not allow usernames that just differ in
capitalization  ("JDoe" vs. "jdoe") to co-exist. (Which could be an argument
for handling users case-insensitive in general)

-- 
Ralf