[
https://issues.apache.org/jira/browse/AMBARI-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15391086#comment-15391086
]
Robert Levas commented on AMBARI-17383:
---------------------------------------
[~tctruong213]
I do not see any issues with Ambari treating usernames as case-insensitive
values.
The argument where a collision between an internal "admin" account being
compromised by an external "Admin" account is not valid since any account in
Ambari can be set to have administrator privileges. Therefore if case
sensitivity was turned back on and there was a local account with the username
"JoeUser" that has administrative privileges, a remote account with the same
username would compromise it.
Fortunately, Ambari keeps local and remote accounts separate so colliding
usernames do not represent the same account in Ambari. This helps to prevent
that admin/Admin and similar issues. However, I have to admit that I am not too
keen on the current implementation since Ambari supports users from difference
sources - LOCAL, LDAP, JWT (SSO) - where there may be an ambiguity in how to
handle accounts with the same username but different sources. The most obvious
issue is how the REST API works in relation to users. The API entry point for
a user is
{noformat}
/api/v1/users/:USERNAME
{noformat}
Notice there is no indication of source. So this call can return or set the
wrong user's info if there are user accounts for the same username
(case-sensitive or not) but different sources.
Back to the issue at hand and how this case-sensitivity issue affects PAM
support (AMBARI-12263). As you have indicated, some OSs are case sensitive and
some are not. For example CentOS is, but Darwin (MacOS) is not. Also LDAP
servers may or may not distinguish between accounts based on case - this is not
consistent between LDAP server vendors. That said, if a system administrator
creates user accounts with usernames differing only in case (rlevas vs. RLevas
vs. etc...) expecting users to properly distinguish between them would be a big
mistake and I have to assume that this is never done. However, I can imagine
that there may be an issue when coming from Ambari if Ambari is storing the
username as all lowercase but the OS has a user with one or more uppercase
characters. This adds to the argument that the user account infrastructure
needs to be reworked when it comes to the source of user authentication - which
goes beyond just case-sensitivity.
I propose that we start a thread in the community to discuss a new user storage
and authentication model. With more and more enterprise-level features being
added to Ambari, we really need to address how to properly integrate with
remote sources - including, but not limited to, LDAP, PAM, SSO/JWT, Kerberos,
etc... Ultimately, user accounts should be identified by a unique user account
identifier (userid) where each account may allow for one or more sources of
authentication. Upon logging in to Ambari, the source of authentication must
then be specified. I am not too sure how this will work when authenticating in
a REST API call, but I think this may be the direction to investigate.
That said, for now, I still think Ambari itself should maintain
case-insensitive usernames.
CC: [~mpapirkovskyy], [~smnaha], [~sumitmohanty]
> User names should be case insensitive
> -------------------------------------
>
> Key: AMBARI-17383
> URL: https://issues.apache.org/jira/browse/AMBARI-17383
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.4.0
> Reporter: Nahappan Somasundaram
> Assignee: Nahappan Somasundaram
> Priority: Critical
> Fix For: 2.4.0
>
> Attachments: rb49119 (1).patch
>
>
> User names should be case insensitive. The following usernames are the same:
> VIEWUSER
> viewUser
> viewuser
> Before adding a new user, a case sensitive search is made. Change this to
> case insensitive. Additionally, store user names in the DB in lower case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
