[
https://issues.apache.org/jira/browse/NIFI-3115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy LoPresto updated NIFI-3115:
--------------------------------
Attachment: Screen Shot 2016-11-28 at 6.57.43 PM.png
User-specific policy view dialog
> 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)
