Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.4.0
    • Fix Version/s: 2.4.0
    • Component/s: ambari-server
    • Labels:
      None

      Description

      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.

      1. rb49119 (1).patch
        21 kB
        Nahappan Somasundaram

        Issue Links

          Activity

          Hide
          hadoopqa Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12812674/rb49119.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 2 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in ambari-server:

          org.apache.ambari.server.security.authorization.AmbariUserAuthenticationFilterTest
          org.apache.ambari.server.stack.StackManagerTest
          org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderForDNWithSpaceTest
          org.apache.ambari.server.security.SecurityHelperImplTest
          org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderTest
          org.apache.ambari.server.api.services.AmbariMetaInfoTest
          org.apache.ambari.server.upgrade.UpgradeCatalog240Test
          org.apache.ambari.server.api.services.KerberosServiceMetaInfoTest

          Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/7493//testReport/
          Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/7493//console

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - -1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12812674/rb49119.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 2 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. -1 core tests . The patch failed these unit tests in ambari-server: org.apache.ambari.server.security.authorization.AmbariUserAuthenticationFilterTest org.apache.ambari.server.stack.StackManagerTest org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderForDNWithSpaceTest org.apache.ambari.server.security.SecurityHelperImplTest org.apache.ambari.server.security.authorization.AmbariLdapAuthenticationProviderTest org.apache.ambari.server.api.services.AmbariMetaInfoTest org.apache.ambari.server.upgrade.UpgradeCatalog240Test org.apache.ambari.server.api.services.KerberosServiceMetaInfoTest Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/7493//testReport/ Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/7493//console This message is automatically generated.
          Hide
          hadoopqa Hadoop QA added a comment -

          +1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12812985/rb49119%20%281%29.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 5 new or modified test files.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          +1 core tests. The patch passed unit tests in ambari-server.

          Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/7525//testReport/
          Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/7525//console

          This message is automatically generated.

          Show
          hadoopqa Hadoop QA added a comment - +1 overall . Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12812985/rb49119%20%281%29.patch against trunk revision . +1 @author . The patch does not contain any @author tags. +1 tests included . The patch appears to include 5 new or modified test files. +1 javac . The applied patch does not increase the total number of javac compiler warnings. +1 release audit . The applied patch does not increase the total number of release audit warnings. +1 core tests . The patch passed unit tests in ambari-server. Test results: https://builds.apache.org/job/Ambari-trunk-test-patch/7525//testReport/ Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/7525//console This message is automatically generated.
          Hide
          tctruong213 Tuong Truong added a comment -

          Hi Nahappan Somasundaram, Sumit Mohanty Robert Levas, we just tripped over this JIRA while trying to test our PAM integration implementation (https://issues.apache.org/jira/browse/AMBARI-12263). Previous JIRA to make Ambari UI case-sensitive (https://issues.apache.org/jira/browse/AMBARI-13997) was not fully complete which causde an error reported in AMBARI-17359. I feel we should have addressed AMBARI-17359 properly by complete the support for case-sensitive userid instead.

          This JIRA has reverted the case-sensitivity support, and while this change may be OK for Ambari private users, but OS users and other directory services (LDAP/AD) are typically case sensitive. The case-insensitive support has created some inconsistency problems when integrating with PAM and even LDAP with granting permission to users in Ambari (since they are all lower-case). This is because admin and Admin will be mapped to admin. So this open a potential for identity hijiack in term of the authority granting in Ambari.

          I think we should revisit the decision of case insensitivity support. What do you think? We do have some customers requesting case-sensitivty support in Ambari.

          Show
          tctruong213 Tuong Truong added a comment - Hi Nahappan Somasundaram , Sumit Mohanty Robert Levas , we just tripped over this JIRA while trying to test our PAM integration implementation ( https://issues.apache.org/jira/browse/AMBARI-12263 ). Previous JIRA to make Ambari UI case-sensitive ( https://issues.apache.org/jira/browse/AMBARI-13997 ) was not fully complete which causde an error reported in AMBARI-17359 . I feel we should have addressed AMBARI-17359 properly by complete the support for case-sensitive userid instead. This JIRA has reverted the case-sensitivity support, and while this change may be OK for Ambari private users, but OS users and other directory services (LDAP/AD) are typically case sensitive. The case-insensitive support has created some inconsistency problems when integrating with PAM and even LDAP with granting permission to users in Ambari (since they are all lower-case). This is because admin and Admin will be mapped to admin. So this open a potential for identity hijiack in term of the authority granting in Ambari. I think we should revisit the decision of case insensitivity support. What do you think? We do have some customers requesting case-sensitivty support in Ambari.
          Hide
          rlevas Robert Levas added a comment -

          Tuong Truong

          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

          /api/v1/users/:USERNAME
          

          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: Myroslav Papirkovskyi, Nahappan Somasundaram, Sumit Mohanty

          Show
          rlevas Robert Levas added a comment - Tuong Truong 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 /api/v1/users/:USERNAME 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: Myroslav Papirkovskyi , Nahappan Somasundaram , Sumit Mohanty

            People

            • Assignee:
              smnaha Nahappan Somasundaram
              Reporter:
              smnaha Nahappan Somasundaram
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development