NiFi Authentication Mechanisms

[Matt Gilman <ma...@gmail.com>]

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

Re: NiFi Authentication Mechanisms

[larry mccay <la...@gmail.com>]

I would like to also bring up the fact that the Hadoop project has a module
for adding kerberos/spnego for Web UIs and REST APIs.
The hadoop-auth module from hadoop is basically a servlet filter with
pluggable authenticationHandlers as delegates.

This will buy you spnego authentication along with the Hadoop specific
delegation token support.

In addition to this, you likely want to consider the trusted proxy support
that REST APIs in Hadoop need in order for Apache Knox or another gateway
to invoke APIs on the behalf of endusers.

Maybe I will file a JIRA for this in nifi and keep it out of this thread. :)

On Tue, Oct 6, 2015 at 2:22 PM, Andrew Hulbert <ah...@ccri.com> wrote:

> Plain LDAP-based user/password auth in addition to Active
> Directory/Kerberos.
>
> You'll get that with Spring Security which I also vote for because it's
> highly pluggable.
>
> Spring security can also be used for pluggable Role assignment via the
> Spring GrantedAuthorities mechanism that's currently in the nifi users XML
> file in addition to the Authentication methods. I've had good success using
> Spring for things like that.
>
>
> On 10/06/2015 11:23 AM, Michael Kobit wrote:
>
>> To add to the list of considerations here:
>>
>> U2F and UAF [1]
>>
>> [1] https://fidoalliance.org/specifications/overview/
>>
>>
>> On Mon, Oct 5, 2015 at 11:39 PM Sumanth Chinthagunta <xm...@gmail.com>
>> wrote:
>>
>> JSON Web Tokens (JWT)  can be an option.
>>> It will provide claims required for authorization without needing
>>> verification with issuer.
>>> Auth0.com has more info on this method.
>>> JWT can be use to propagate identity along the flow so that it can be
>>> used
>>> later by processors
>>>
>>> On Mon, Oct 5, 2015, 7:41 PM Rick Braddy <rb...@softnas.com> wrote:
>>>
>>> SSO is another important consideration.
>>>>
>>>> Spring Security looks like a winner. Very impressive list of support.
>>>>
>>>>
>>>> On Oct 5, 2015, at 9:34 PM, larry mccay <lm...@apache.org> wrote:
>>>>>
>>>>> 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 <tr...@gmail.com> 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 <rb...@softnas.com>
>>>>>>>
>>>>>> 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 <jo...@gmail.com> 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 <rb...@softnas.com>
>>>>>>>>>
>>>>>>>> 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 <ma...@gmail.com>
>>>>>>>>>>
>>>>>>>>> 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
>>>
>>
>

Re: NiFi Authentication Mechanisms

[Andrew Hulbert <ah...@ccri.com>]

Plain LDAP-based user/password auth in addition to Active 
Directory/Kerberos.

You'll get that with Spring Security which I also vote for because it's 
highly pluggable.

Spring security can also be used for pluggable Role assignment via the 
Spring GrantedAuthorities mechanism that's currently in the nifi users 
XML file in addition to the Authentication methods. I've had good 
success using Spring for things like that.

On 10/06/2015 11:23 AM, Michael Kobit wrote:
> To add to the list of considerations here:
>
> U2F and UAF [1]
>
> [1] https://fidoalliance.org/specifications/overview/
>
>
> On Mon, Oct 5, 2015 at 11:39 PM Sumanth Chinthagunta <xm...@gmail.com>
> wrote:
>
>> JSON Web Tokens (JWT)  can be an option.
>> It will provide claims required for authorization without needing
>> verification with issuer.
>> Auth0.com has more info on this method.
>> JWT can be use to propagate identity along the flow so that it can be  used
>> later by processors
>>
>> On Mon, Oct 5, 2015, 7:41 PM Rick Braddy <rb...@softnas.com> wrote:
>>
>>> SSO is another important consideration.
>>>
>>> Spring Security looks like a winner. Very impressive list of support.
>>>
>>>
>>>> On Oct 5, 2015, at 9:34 PM, larry mccay <lm...@apache.org> wrote:
>>>>
>>>> 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 <tr...@gmail.com> 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 <rb...@softnas.com>
>>> 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 <jo...@gmail.com> 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 <rb...@softnas.com>
>>>>>> 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 <ma...@gmail.com>
>>>>>> 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

Re: NiFi Authentication Mechanisms

[Michael Kobit <mk...@gmail.com>]

To add to the list of considerations here:

U2F and UAF [1]

[1] https://fidoalliance.org/specifications/overview/


On Mon, Oct 5, 2015 at 11:39 PM Sumanth Chinthagunta <xm...@gmail.com>
wrote:

> JSON Web Tokens (JWT)  can be an option.
> It will provide claims required for authorization without needing
> verification with issuer.
> Auth0.com has more info on this method.
> JWT can be use to propagate identity along the flow so that it can be  used
> later by processors
>
> On Mon, Oct 5, 2015, 7:41 PM Rick Braddy <rb...@softnas.com> wrote:
>
> > SSO is another important consideration.
> >
> > Spring Security looks like a winner. Very impressive list of support.
> >
> >
> > > On Oct 5, 2015, at 9:34 PM, larry mccay <lm...@apache.org> wrote:
> > >
> > > 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 <tr...@gmail.com> 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 <rb...@softnas.com>
> > 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 <jo...@gmail.com> 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 <rb...@softnas.com>
> > >>> 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 <ma...@gmail.com>
> > >>> 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
> > >>
> >
>

Re: NiFi Authentication Mechanisms

[Sumanth Chinthagunta <xm...@gmail.com>]

JSON Web Tokens (JWT)  can be an option.
It will provide claims required for authorization without needing
verification with issuer.
Auth0.com has more info on this method.
JWT can be use to propagate identity along the flow so that it can be  used
later by processors

On Mon, Oct 5, 2015, 7:41 PM Rick Braddy <rb...@softnas.com> wrote:

> SSO is another important consideration.
>
> Spring Security looks like a winner. Very impressive list of support.
>
>
> > On Oct 5, 2015, at 9:34 PM, larry mccay <lm...@apache.org> wrote:
> >
> > 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 <tr...@gmail.com> 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 <rb...@softnas.com>
> 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 <jo...@gmail.com> 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 <rb...@softnas.com>
> >>> 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 <ma...@gmail.com>
> >>> 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
> >>
>

Re: NiFi Authentication Mechanisms

[Rick Braddy <rb...@softnas.com>]

SSO is another important consideration.

Spring Security looks like a winner. Very impressive list of support.


> On Oct 5, 2015, at 9:34 PM, larry mccay <lm...@apache.org> wrote:
> 
> 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 <tr...@gmail.com> 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 <rb...@softnas.com> 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 <jo...@gmail.com> 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 <rb...@softnas.com>
>>> 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 <ma...@gmail.com>
>>> 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
>> 

Re: NiFi Authentication Mechanisms

[larry mccay <lm...@apache.org>]

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 <tr...@gmail.com> 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 <rb...@softnas.com> 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 <jo...@gmail.com> 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 <rb...@softnas.com>
> > 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 <ma...@gmail.com>
> > 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
> >
>

Re: NiFi Authentication Mechanisms

[Tony Kurc <tr...@gmail.com>]

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 <rb...@softnas.com> 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 <jo...@gmail.com> 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 <rb...@softnas.com>
> 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 <ma...@gmail.com>
> 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
>

Re: NiFi Authentication Mechanisms

[Rick Braddy <rb...@softnas.com>]

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 <jo...@gmail.com> 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 <rb...@softnas.com> 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 <ma...@gmail.com> 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

Re: NiFi Authentication Mechanisms

[Joe Witt <jo...@gmail.com>]

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 <rb...@softnas.com> 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 <ma...@gmail.com> 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

Re: NiFi Authentication Mechanisms

[Rick Braddy <rb...@softnas.com>]

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 <ma...@gmail.com> 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