Andy LoPresto created NIFI-3115:
-----------------------------------
Summary: 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
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)
