...
- 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 two a simple methods such as method 'isAuthorized' and 'getAuthorizationHistory'. In the case of . 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. In the case of 'getAuthorizationHistory' 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.
- 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.
...
- 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'
...