THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Goals
- Provide new authentication mechanisms inclusive of a foundational framework that allows specific authentication providers. Best in class for this situation appears from a cursory standpoint to be JAAS
- Build the needed extensions and configuration to allow for multiple providers along the likes of LDAP, Kerberos, OAuth/OpenID Connect, etc.
- Extend the UI to provide a consistent user experience for interfacing with any of the various providers
Background and strategic fit
Current security mechanisms are Spring based and heavily bound to exclusively a PKI powered system. There has been wide community request for supporting of additional mechanisms as they look to provide integration of NiFi into existing enterprise facilities. Work to this end would allow the assignment of roles within NiFi instances.
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Provide a framework for implementing multiple authentication providers | There are wide and varying authentication mechanisms in place across various enterprises. Accordingly, it is important to provide a consistent interface for integration within various environments as well as providing a basis for custom implementations. |
| |
| 2 | LDAP Provider | |||
| 3 | Kerberos Provider | |||
| 4 | OAuth2/OpenID Connect |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|
| What best addresses the problem in terms of our needs and technology? Dispelling differences between SASL and JAAS and their applicability. | |
| What is a core set of providers that cover most needs? | |
| How does this affect user model in terms of groups and access? How does it affect our compliance with SCIM? | |
| How does this affect the authority provider? |