ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Updated] (AMBARI-20859) Improve User Account Management Within Ambari
Date Sun, 14 Jan 2018 13:37:00 GMT


ASF GitHub Bot updated AMBARI-20859:
    Labels: authentication pull-request-available security user_management  (was: authentication
security user_management)

> Improve User Account Management Within Ambari
> ---------------------------------------------
>                 Key: AMBARI-20859
>                 URL:
>             Project: Ambari
>          Issue Type: Epic
>          Components: ambari-server, ambari-web
>    Affects Versions: 3.0.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>              Labels: authentication, pull-request-available, security, user_management
>             Fix For: 3.0.0
> As of Ambari 2.4, user management is confusing and tends to lead to inconsistent results
during synchronization and authentication.  With the addition of new mechanisms such as Kerberos
and PAM, this will only get worse.  Therefore, there is a need to rework how Ambari manages
users to ensure that new authentication facilities are easily integrated.
> The following problems need to be solved:
> * *Case-sensitivity*
> Some authentication sources are case sensitive and some are not.  Ambari inconsistently
handles the case of user names leading to confusing where user metadata is being created or
being overwritten.  This issue extends from the front end through the backend and to the database
> * *Username Collisions*
> There are several cases where username collisions occur.  One is where a username exists
as a local user as well as an external user.  For example, the initial administrator account
has is a local user account with the username of "admin".  There may also be an external user
account with the username "admin". In some cases Ambari will treat both accounts as the same
user, converting the local account during synchronization operation to an LDAP account. However
in other cases, Ambari will treat the accounts as separate users and create a separate account.
> * *REST API*
> Due to the implementation of the user resource in the REST API, there is no way to distinguish
between user accounts with the same username and different data sources. For example usera/LOCAL
vs usera/LDAP.  This is because the primary key for user resources is only the username field.
 This make managing users confusing since the REST API entrypoint for user resources is /api/v1/users/:USERNAME
and there is no way to retrieve or set the details for a specific user. 

This message was sent by Atlassian JIRA

View raw message