The wiki page seems to describe continuing to use Spring Security. I believe this to be a wise choice.
I would encourage you to try and expose the capabilities of that framework as much as possible rather than providing support for a constrained set of providers. SSO integrations are becoming important for a number of ecosystem projects and UIs for instance. The ability to add a custom authentication provider will be important for such usecases. On Mon, Oct 5, 2015 at 10:10 PM, Tony Kurc <[email protected]> wrote: > I'd like to see Duo Web two-factor https://www.duosecurity.com/docs/duoweb > > On Mon, Oct 5, 2015 at 10:00 PM, Rick Braddy <[email protected]> wrote: > > > 1) Basic password authentication with Recaptcha after N failed logins > > (encrypted password storage) > > > > 2) 2-factor Google Auth option to supplement password logins > > > > 3) Active Directory / Kerberos auth (with 2-factor option as well) > > > > > On Oct 5, 2015, at 8:56 PM, Joe Witt <[email protected]> wrote: > > > > > > Thanks Rick. If you were to say which of that you'd want 'first' and > > > then which you can see coming later please advise. > > > > > > All: Please do just that - let us know which you need 'now' and which > > > you can wait on. > > > > > > Thanks > > > Joe > > > > > >> On Mon, Oct 5, 2015 at 9:53 PM, Rick Braddy <[email protected]> > > wrote: > > >> Matt, > > >> > > >> Here you go: > > >> > > >> - 2-factor Google Authenticator to supplement password auth (e.g. to > > strengthen password with mobile phone onetime ID or other support strong > > auth options) > > >> > > >> - Recaptcha required after N failed password login attempts to block > > brute force attacks (e.g. 5 failed logins, then captcha required) > > >> > > >> - Password strength policies > > >> > > >> - PAM support provides pluggable authentication options, at least for > > Linux (better than locally stored passwords) > > >> > > >> - Active Directory Kerberos integration (Windows native and Linux) > > >> > > >> If passwords to be stored locally, must be encrypted. > > >> > > >> Hope that helps. > > >> > > >> Rick > > >> > > >>> On Oct 5, 2015, at 8:34 PM, Matt Gilman <[email protected]> > > wrote: > > >>> > > >>> All, > > >>> > > >>> I've started working on providing additional authentication > mechanisms > > for > > >>> the NiFi user interface. Currently, only two way SSL using client > > >>> certificates is supported to authenticate users. I would like to > > inquire > > >>> about which other mechanisms the community would like to see > > implemented. > > >>> > > >>> We have created a feature proposal discussing some of the options > [1]. > > At a > > >>> high level, in additional to PKI, we are looking at > > >>> > > >>> - Username/password > > >>> -- stored in a local configuration file (ie authorized-users.xml) > > >>> -- stored in a configurable LDAP > > >>> -- stored in a configurable database > > >>> - Kerberos > > >>> - OpenId Connect > > >>> > > >>> What other options are important and should be added to the list? > > Thanks! > > >>> > > >>> Matt > > >>> > > >>> [1] > > >>> > > > https://cwiki.apache.org/confluence/display/NIFI/Pluggable+Authentication > > >
