[jira] [Commented] (NIFI-3115) Enhance user policy management functionality

["Andrew Lim (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15749400#comment-15749400 ] 

Andrew Lim commented on NIFI-3115:
----------------------------------

Lots of good ideas here [~alopresto], especially to streamline the user creation process (with and without policies).  I definitely looked at NIFI-2926 as the first stage for the User Policies window.  As you suggested, there are ways to make that window more interactive/powerful, so that is doesn't just show a user's policies, but allows management of those policies as well.

> Enhance user policy management functionality
> --------------------------------------------
>
>                 Key: NIFI-3115
>                 URL: https://issues.apache.org/jira/browse/NIFI-3115
>             Project: Apache NiFi
>          Issue Type: New Feature
>          Components: Core Framework, Core UI
>    Affects Versions: 1.1.0
>            Reporter: Andy LoPresto
>            Priority: Critical
>              Labels: dac, permissions, policy, rbac, user
>         Attachments: Screen Shot 2016-11-28 at 6.57.43 PM.png
>
>
> With the multi-tenant authorization model introduced in version 1.1.0, NiFi has moved from role-based access control (RBAC) to a more granular combination of discretionary access control (DAC) (permissions based on individual user credentials combined with membership in groups) and permission-based access control (granting explicit behavioral access on individual resources to specific users and groups). See [Overview of Access Control Models|https://www.owasp.org/index.php/Access_Control_Cheat_Sheet] for more details. 
> Because of this change, centralized management of user permissions ("policy in NiFi terminology) can be complex. For example, to add a new user with the same policies as the "Initial Administrator Identity" requires approximately 55 clicks, and to add a user with all policies would take approximately 80. Currently, the mental model appears to me to be policy-focused as opposed to user-focused. This makes sense as the development of these features was highly-focused on policy definition, and in default deployments, the number of policies outnumbers the number of users. Much like [NIFI-2926] streamlined viewing the policies assigned to a user across the entire application, I propose a couple of features to make user/policy management much easier. 
> I believe these should be broken out into subtasks of this ticket, but I am including all of my thoughts in the ticket description to facilitate discussion in a single location. Once the community has weighed in, they can be subdivided. 
> * Clone user feature
> ** This feature would allow an administrator/user with necessary user management permissions to clone an existing user and copy their permissions. This is useful for adding new members of a team with the expectation that they would gain access to the same resources and global policies granted to a colleague at a similar level of job responsibility. This feature should be implemented in a way that the policies are cloned but not related -- i.e. if Andy has permission X and Matt is a clone, Matt should have permission X permanently, even if Andy loses permission X tomorrow. 
> * New user policy definition dialog
> ** Similar to the attached screenshot for viewing policies assigned to a user, I suggest a feature where a specific user or group can be selected and all available global and per-resource policies on the system are exposed as a list with checkboxes or a ternary selector if applicable (NONE, READ, READ+WRITE). The existing policies for the user/group would be pre-populated/selected. This would allow the rapid creation of a new user with appropriate policy assignment without cloning an existing user, and the rapid application of new policies to an existing user/group. 
> * Batch user import
> ** Whether the users are providing client certificates, LDAP credentials, or Kerberos tickets to authenticate, the canonical source of identity is still managed by NiFi. I propose a mechanism to quickly define multiple users in the system (without affording any policy assignments). Here I am looking for substantial community input on the most common/desired use cases, but my initial thoughts are:
> *** One user per line in a text file/pastable text area in a UI dialog
> **** Each line is parsed and a user defined with the provided username
> *** LDAP-specific
> **** A manager DN and password (similar to necessary for LDAP authentication) are used to authenticate the admin/user manager, and then a LDAP query string (i.e. {{ou=users,dc=nifi,dc=apache,dc=org}}) is provided and the dialog displays/API returns a list of users/groups matching the query. The admin can then select which to import to NiFi and confirm. 
> *** Kerberos-specific
> **** No existing thoughts
> *** Client certificate-specific
> **** No way to know all client certificates signed by the CA cert a priori without integration to CA (even then, intermediate signatures could raise issues)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)