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.
- Build the needed extensions and configuration to allow for multiple providers along the likes of Username/Password, Kerberos, OAuth/OpenID Connect, etc.
- Update the UI to support supplying username/password when configured.
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. Using Spring Security allows for supporting any of these options.
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | 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 | Username/Password Provider | Active Directory, LDAP | ||
| 3 | Kerberos Provider | |||
| 4 | PKI Provider | |||
| 5 | 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. | By sticking with Spring Security we can eventually offer support for both |
| What is a core set of providers that cover most needs? | PKI, Username/Password (Active Directory, LDAP), Keberos |
| How does this affect user model in terms of groups and access? How does it affect our compliance with SCIM? | It does not affect it. This simply provides support for identifying a user. Access and groups are handled by the AuthorityProvier |
| How does this affect the authority provider? | It does not impact the AuthorityProvider |
| When using Username/Password how do we establish site to site communication? When using OpenId Connect how do we establish site to site communication? | Since certificates are necessary for establishing secure connectors in the web server, we can still rely on certificates for site to site and cluster communications. |
1 Comment
Shaunak Ashtaputre
Does this feature also cover SAML integration?