[
https://issues.apache.org/jira/browse/GUACAMOLE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17887719#comment-17887719
]
Nick Couchman commented on GUACAMOLE-1239:
------------------------------------------
[~mjumper] I may need your assistance with this one, it has me rather stumped
at the moment. The errors being reported on the mailing list ([1]) are come
from this block of code in the ModeledDirectoryObjectService class ([2]):
{code:java}
@Override
public Collection<InternalType> retrieveObjects(ModeledAuthenticatedUser
user,
Collection<String> identifiers) throws GuacamoleException {
// Ignore invalid identifiers
List<String> filteredIdentifiers = filterIdentifiers(identifiers);
// Do not query if no identifiers given
if (filteredIdentifiers.isEmpty())
return Collections.<InternalType>emptyList();
int batchSize = environment.getBatchSize();
boolean userIsPrivileged = user.isPrivileged();
// Process the filteredIdentifiers in batches using Lists.partition()
and flatMap
Collection<ModelType> allObjects = Lists.partition(filteredIdentifiers,
batchSize).stream()
.flatMap(chunk -> {
Collection<ModelType> objects;
// Bypass permission checks if the user is privileged
if (userIsPrivileged)
objects = getObjectMapper().select(chunk);
// Otherwise only return explicitly readable identifiers
else
objects =
getObjectMapper().selectReadable(user.getUser().getModel(),
chunk, user.getEffectiveUserGroups());
return objects.stream();
})
.collect(Collectors.toList());
// Return collection of requested objects
return getObjectInstances(user, allObjects);
}
{code}
This is happening because the "caseSensitive" parameter has been added to the
methods in the UserMapper interface, but since this particular method doesn't
distinguish between the various implementations of the
ModeledDirectoryObjectMapper classes, it calls the ones that don't have the
parameter, and then results in the errors that are being reported. It seems a
bit excessive to continue down the path of untangling the UserMapper interface
fom the ModeledDirectoryObjectMapper interface, but I've got a severe mental
block on how else go go about it?
The fact that the implementation of UserMapper is handled
transparently/dynamically by MyBatis is making it challenging to use any of the
Guice injection to pull the Environment directly into the class, but I've got
to be missing something?
1 - https://lists.apache.org/thread/kstbwqvv458m15g15bkfbxgn253pw9cg
2 -
https://github.com/apache/guacamole-client/blob/d433a2751cfdfacf8cd8897e3bfe419f85a69e70/extensions/guacamole-auth-jdbc/modules/guacamole-auth-jdbc-base/src/main/java/org/apache/guacamole/auth/jdbc/base/ModeledDirectoryObjectService.java#L396-L431
> Make usernames case insensitive in DB
> --------------------------------------
>
> Key: GUACAMOLE-1239
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-1239
> Project: Guacamole
> Issue Type: Improvement
> Components: Documentation, guacamole-auth-jdbc,
> guacamole-auth-jdbc-mysql, guacamole-auth-jdbc-postgresql, guacamole-auth-ldap
> Reporter: Magnus Lübeck
> Assignee: Nick Couchman
> Priority: Minor
> Fix For: 1.6.0
>
>
> [~cameronp] already summarized this well in GUACAMOLE-404:
>
> Quote:
> "We have ldap auth working for us via active directory. We have issues with
> case senstivity around logins. For example most users have no idea if their
> username is
> User.Name
> or USER.NAME or whatever. - active directory doesnt care about case, and
> neither does ldap authentication.
> But when they log in to guac and do not match the case of their login
> exactly, guac allows them to log in, but they just don't have any machines to
> connect to.
> Wondering if it could be made to either fail the logins if it doesn't match
> correct case, or ignore case when matching the username in the local guac db."
>
> So, when I ran across GUACAMOLE-404, and this email
> [https://www.mail-archive.com/dev@guacamole.apache.org/msg03715.html] where
> [~vnick] discuss this topic in depth, I realized that I need to chip in my
> point of view. In the documentation it is mentioned that one can restrict
> user login, to avoid confusion that a user can log in per LDAP but not have
> any connections,
> http://guacamole.incubator.apache.org/doc/gug/jdbc-auth.html#jdbc-auth-restrict.
> I am not sure where I would start lobbying for either asking for a default
> case insensitive username management, or the option to make the
> Postgresql/Mysql/etc usernames case insensitive. I would happily chip in
> time, money, or other stimulus to bring this discussion further.
>
> This writeup from google is a text I have visited from time to time, as I
> think it is well written and makes many points in a clear manner.
> [https://cloud.google.com/blog/products/gcp/12-best-practices-for-user-account]
>
> Point 11: Make user IDs case insensitive
> Quote:
> "Your users don't care and may not even remember the exact case of their
> username. Usernames should be fully case-insensitive. It's trivial to store
> usernames and email addresses in all lowercase and transform any input to
> lowercase before comparing.
> Smartphones represent an ever-increasing percentage of user devices. Most of
> them offer autocorrect and automatic capitalization of plain-text fields.
> Preventing this behavior at the UI level might not be desirable or completely
> effective, and your service should be robust enough to handle an email
> address or username that was unintentionally auto-capitalized."
>
> I had a very long discussion about this with a work colleague today. He has
> to support a group of customers, of which we get a list of CAPITALIZED
> usernames to import into our Active Directory domain controller. These users
> are quite used to work in an environment where they don't have to care. I
> have observed our customers log in and many users either log in with their
> username in lowercase, some log in with their username's first letter
> CAPITALIZED. Very rarely do they log in with all caps.
>
> To make matters a bit worse, is that we integrate Guacamole with oauth2_proxy
> in front of it. Oauth2_proxy sends the users first to our KeyCloak
> installation, which happily authenticates the user with any permutation they
> choose to enter. Since we do want to have the users log into the RDP servers
> with their own credentials they are asked to log in again (a 2nd time, since
> we don't get the password through otherwise). It is very confusing for our
> users that they can log into KeyCloak but not into Guacamole.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
