[DISCUSS] Usernames and Case Sensitivity

[Nick Couchman <vn...@apache.org>]

Okay, everyone,
I'm hitting a bit of an issue with case sensitivity in the Guacamole
usernames, and I'd like to discuss the best way to handle this as a
community.  The various authentication components of Guacamole Client have
varying apparent levels of case sensitivity.  For example:
- The JDBC module is case-sensitive for username - so, if I create a user
"Nick" in the database, I cannot log in with "nick" or "NICK" or "Nick",
etc.
- LDAP implementations are, in my experience, almost universally
implemented with case-insensitivity for usernames - that is, when I bind to
OpenLDAP or Active Directory, the username and/or DN that I use can be any
mixture of upper and lower-case, and the actual object is matched without
regard to case.  So, I might have "cn=Nick,ou=Users,dc=apache,dc=org" and I
can use that or "CN=NICK,OU=USERS,DC=APACHE,DC=ORG", or
"cn=nick,ou=users,dc=apache,dc=org" and all values resolve to the same
object within the tree.  This isn't true for all LDAP attributes, but tends
to be true for identifying ones - like CN, uniqueId, sAMAccountName, etc.
- SSO modules tends to be case-insensitive, but also may depend on an
underlying authentication system for that (LDAP, for example) - so, when I
log into a SAML system with my e-mail address (usually not case sensitive),
I can log in with any combination of case within the characters of that
address and it is still "my" account.

Guacamole, when it does its comparison of usernames between the various
modules in order to match a user authenticated from one with another (e.g
JDBC user authenticated with LDAP), is most definitely case-sensitive.  So,
the behavior that I currently experience, that I consider undesirable, is
this:
- I configure Guacamole Client for both JDBC and LDAP (layered)
authentication.
- I log in with "guacadmin" and assign my LDAP user ("nick") System Admin
privileges within Guacamole Client.
- I log in with "nick" and my LDAP password, and then I go look at the
available users (which are pulled from LDAP) and assign them rights to
connections within the system.  Let's say LDAP gives me the users "Bob",
"John", and "Lucy".
- Lucy logs into the system using her LDAP username and password.  Instead
of "Lucy", though, she logs in with "lucy" and her password, which is still
matched to her LDAP DN due to the case-insensitive nature of the LDAP
search.
- Because "Lucy" != "lucy", Lucy receives no privileges within the system -
no access to the connections to which the account "Lucy" has been
assigned.  Therefore, Lucy has to be instructed to log in with "lucy", all
lower-case, whereupon she receives the correct connection access.

This results in either confusion for the users - the login works, but the
permissions are not applied as expected - or extra work for the admins - I
have to create "Lucy" and "lucy" (and maybe even "LUCY", "lUCY",
"LUcy"...etc.) within the database and assign all of the variations the
same permissions, else the user may get logged in with some combination
that results in missing permissions.

So, my question to the community is, what is the best way to handle this?
My experience is that most authentication systems (LDAP, AD, SSO/SAML) tend
to be case-insensitive with regard to usernames, but that's certainly not
universally true.  It seems like there are several possible options:
- Make Guacamole completely case-insensitive for usernames, so that, both
within the internal DB authentication mechanism, and while comparing
usernames among various modules.
- Allow each individual module to be configured for its level of case
sensitivity with regard to usernames, including DB, LDAP, SSO, RADIUS,
etc.  The challenge with this would be to make sure behavior is consistent
between modules when one is configured for case sensitivity and one is not
(like the current behavior between DB and LDAP).
- Allow entire system to be configured for case-sensitivity, such that all
modules are either case-sensitive, or they are not.  The issue that I see
with this is that we would likely have to do some extra work on some of the
modules to veto otherwise successful results - for example, in LDAP, if I
log in with "nick" but the actual sAMAccountName value is "NicK", and LDAP
says that's okay/good, we would need to be ready/able to veto that result
within Guacamole because, even though the back-end said it was okay, it
actually doesn't match.

Other directions people can think of?  Thoughts?  Opinions?  Suck it up and
deal with it, Nick, and tell the users to pay attention to their usernames?

-Nick

Re: [DISCUSS] Usernames and Case Sensitivity

[Sean Reid <se...@gmail.com>]

Nick,

My view is that Guacamole should be completely case-insensitive for
usernames. In my experience, most auth systems are case-insensitive for
usernames and I think that average user is conditioned to think it would
be. Putting each username through a toLower() before it's handed off to an
underlying module seems like a good, consistent approach to me.

Just my two cents,
Sean

On Thu, Oct 31, 2019 at 9:49 PM Nick Couchman <vn...@apache.org> wrote:

> Okay, everyone,
> I'm hitting a bit of an issue with case sensitivity in the Guacamole
> usernames, and I'd like to discuss the best way to handle this as a
> community.  The various authentication components of Guacamole Client have
> varying apparent levels of case sensitivity.  For example:
> - The JDBC module is case-sensitive for username - so, if I create a user
> "Nick" in the database, I cannot log in with "nick" or "NICK" or "Nick",
> etc.
> - LDAP implementations are, in my experience, almost universally
> implemented with case-insensitivity for usernames - that is, when I bind to
> OpenLDAP or Active Directory, the username and/or DN that I use can be any
> mixture of upper and lower-case, and the actual object is matched without
> regard to case.  So, I might have "cn=Nick,ou=Users,dc=apache,dc=org" and I
> can use that or "CN=NICK,OU=USERS,DC=APACHE,DC=ORG", or
> "cn=nick,ou=users,dc=apache,dc=org" and all values resolve to the same
> object within the tree.  This isn't true for all LDAP attributes, but tends
> to be true for identifying ones - like CN, uniqueId, sAMAccountName, etc.
> - SSO modules tends to be case-insensitive, but also may depend on an
> underlying authentication system for that (LDAP, for example) - so, when I
> log into a SAML system with my e-mail address (usually not case sensitive),
> I can log in with any combination of case within the characters of that
> address and it is still "my" account.
>
> Guacamole, when it does its comparison of usernames between the various
> modules in order to match a user authenticated from one with another (e.g
> JDBC user authenticated with LDAP), is most definitely case-sensitive.  So,
> the behavior that I currently experience, that I consider undesirable, is
> this:
> - I configure Guacamole Client for both JDBC and LDAP (layered)
> authentication.
> - I log in with "guacadmin" and assign my LDAP user ("nick") System Admin
> privileges within Guacamole Client.
> - I log in with "nick" and my LDAP password, and then I go look at the
> available users (which are pulled from LDAP) and assign them rights to
> connections within the system.  Let's say LDAP gives me the users "Bob",
> "John", and "Lucy".
> - Lucy logs into the system using her LDAP username and password.  Instead
> of "Lucy", though, she logs in with "lucy" and her password, which is still
> matched to her LDAP DN due to the case-insensitive nature of the LDAP
> search.
> - Because "Lucy" != "lucy", Lucy receives no privileges within the system -
> no access to the connections to which the account "Lucy" has been
> assigned.  Therefore, Lucy has to be instructed to log in with "lucy", all
> lower-case, whereupon she receives the correct connection access.
>
> This results in either confusion for the users - the login works, but the
> permissions are not applied as expected - or extra work for the admins - I
> have to create "Lucy" and "lucy" (and maybe even "LUCY", "lUCY",
> "LUcy"...etc.) within the database and assign all of the variations the
> same permissions, else the user may get logged in with some combination
> that results in missing permissions.
>
> So, my question to the community is, what is the best way to handle this?
> My experience is that most authentication systems (LDAP, AD, SSO/SAML) tend
> to be case-insensitive with regard to usernames, but that's certainly not
> universally true.  It seems like there are several possible options:
> - Make Guacamole completely case-insensitive for usernames, so that, both
> within the internal DB authentication mechanism, and while comparing
> usernames among various modules.
> - Allow each individual module to be configured for its level of case
> sensitivity with regard to usernames, including DB, LDAP, SSO, RADIUS,
> etc.  The challenge with this would be to make sure behavior is consistent
> between modules when one is configured for case sensitivity and one is not
> (like the current behavior between DB and LDAP).
> - Allow entire system to be configured for case-sensitivity, such that all
> modules are either case-sensitive, or they are not.  The issue that I see
> with this is that we would likely have to do some extra work on some of the
> modules to veto otherwise successful results - for example, in LDAP, if I
> log in with "nick" but the actual sAMAccountName value is "NicK", and LDAP
> says that's okay/good, we would need to be ready/able to veto that result
> within Guacamole because, even though the back-end said it was okay, it
> actually doesn't match.
>
> Other directions people can think of?  Thoughts?  Opinions?  Suck it up and
> deal with it, Nick, and tell the users to pay attention to their usernames?
>
> -Nick
>