Uploaded image for project: 'Apache NiFi'
  1. Apache NiFi
  2. NIFI-3115

Enhance user policy management functionality

    Details

      Description

      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 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)

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                alopresto Andy LoPresto
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: