Support Authorizer API

Goals

• Enable more powerful and flexible authorization decisions for actions within NiFi that the current role-based model
• Enable support for an external and centralized user/entitlement management service rather than having those decisions embedded in NiFi

Background and strategic fit

The current authorization mechanism of NiFi provides a set of entitlements for a given user/entity.  The in internal code NiFi decides whether that entity and its entitlements fits a given command it plans to run.  This means the current authorization plugin is very limited in what it can convey and that NiFi is limited to only supporting the existing roles for existing methods.  This model is fairly easy to understand but inflexible and doesn't give us the capability we need as we move into Multi-Tenant authorization and perhaps even more interesting authorization schemes later (such as controlling whether a given person should even see a particular processor for adding to the flow, etc...)

Our current approach benefits though from being able to offer a pretty simple user experience whereby a user can be registered for a nifi account and an administrator can elect to give them access to certain defined roles or not.  We can show whether they have been active recently.  This approach works well for for the current inflexible role-based model we have.

A proposed approach is outlined as follows and is broken into two phases.  The first phase should align with NiFi 1.0.0 release and the second phase shall occur by then as well or can slip to a 1.x release shortly thereafter.

Phase1:

• Drop user account request support as we'd move to a simpler scheme whereby given an established identity we ask the authorizer 'can they do this'
• Drop UI based user role update, delete
• Instead all authorization decisions are delegated to the Authorizer API provider.  The API would support a simple method 'isAuthorized'.  With 'isAuthorized', the call would be parameterized with the identity of the entity making the request (could be a chain of requesters/proxy), the resource being accessed, the action being attempted, and a map of contextual information about the request.  The call would then return indicating whether the request is allowed or not and may ideally provide some information that may be shared with the user or in logs as to why not.  
• As for specific implementations of the Authorizer API we could provide a simple FileBasedAuthorizer similar to the current file based authority provider.  And we could implement against Apache Ranger or Apache Sentry which both offer pluggable authorizer modules that go with a given application against a centralized policy store.  In the case of the FileBasedAuthorizer we could still allow for runtime modifications to the accesses and users by letting someone edit the authority configuration by hand and we just automatically reload at runtime.  In the case of Ranger or Sentry module it would inherently delegate that information at runtime so we're good there and it would be both single node and cluster friendly.  FileBased would work sufficiently for single node cases but be awkward in a cluster configuration.

Implications of Phase1:

• Our current Authority Provider API provides limited flexibility to support centralized policy management as it forces a given external authority provider to be mapped into a set of NiFi understood roles "DFM, Admin, Read-Only".  However, it offers a sufficient user experience for those roles and is easy to understand.
• The proposed model offers a far more flexible authorization capability, represents a more efficient separation of concerns.  Stated another way it offers a highly flexible delegated authorization decision model with a lower quality user experience though the user experience for centralized user entitlement management may be better but is a different application.

To improve on the UX tradeoff introduced in phase 1 we propose phase 2:

• Update Authorizer API to support CRUD operations for authorizers that are willing to implement them.  With Java 8 we can feasible extend that interface in a backward compatible way.
• Add UI/Web API to leverage CRUD supporting Authorizers.  This will support some fixed UI concept for entitlement assignment to a given user.  This approach would be good for simple things like the FileBasedAuthorizer but unnecessary for things like Ranger/Sentry which have their own centralized entitlement management model.
• Introduce a 'getAuthorizationHistory' for authorizers that are willing to implement them. The idea is that we could query the Authorizer API for information it might have about recent user access, last heard, last mutable request, last rejection.  Perhaps it could allow for finer grained information to be requested as well for why a rejection occurred and what was being requested.  With this capability the NiFi UI could expose a user table with that information.  We would not strictly be able to show 'all' users necessarily but we could show recent users and what we know about their types/recency of access.

Assumptions

• Users in the 'learning NiFi', 'non-production', 'POC' phase with NiFi will want FileBasedAuthorizer and could live without a UI for managing entitlements so long as they can make changes at runtime to the config file.
• Users in a production use mode will likely want to delegate to a centralized authorization mechanism and having a UI in NiFi to edit entitlements could be limiting for the flexibility of their centralized tool and not a good separation of concerns.
• Regardless we should still find ways to offer a user experience that allows one to see which users have been active recently and to aid in troubleshooting access problems and understanding who has been altering or viewing the flow.
• Formal auditing of actions shall be the job of the Authorizer implementation.  NiFi will still keep a local database of changes made so it can provide a nice user experience around which identities made which changes 'joe changed processor X property Y from A to B'

Requirements

User interaction and design

Questions

Below is a list of questions to be addressed as a result of this requirements document:

Not Doing