You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Joe Witt <jo...@gmail.com> on 2015/12/14 04:21:48 UTC
Re: Basic Authentication
Edgardo
Be sure to check out the 0.4.0 release as it now supports
username/password authentication backed by active directory or
directory server via LDAP.
Thanks
Joe
On Fri, Nov 20, 2015 at 7:42 AM, Edgardo Vega <ed...@gmail.com> wrote:
> Joe,
>
> Right now we currently proxy everything through nginx. Currently nginx asks
> us for our username and password and then forwards the username and says
> they have been authentication. This works okay for nifi if all you want to
> do is use the web interface. But there doesn't seem to be a way to make
> site to site work in this scenario. So we are trying to figure out how to
> secure nifi but not issue certs all over the place. We currently are using
> site to site to get data from someone else as well as use it to send data
> to a few of our own mini clusters. Some of which are in different aws
> regions.
>
> Cheers,
>
> Edgardo
>
> On Fri, Nov 20, 2015 at 7:21 AM, Joe Witt <jo...@gmail.com> wrote:
>
>> Edgardo
>>
>> Yep. What are some others you'd be looking for? What we're basically
>> doing is preferring a delegated provider model. Kerberos is one we
>> plan to knock out as well
>>
>> Thanks
>> Joe
>>
>> On Fri, Nov 20, 2015 at 7:10 AM, Edgardo Vega <ed...@gmail.com>
>> wrote:
>> > Joe,
>> >
>> > Yes I was looking for username and password. Seems like NIFI-655 will
>> setup
>> > the base to allow for other username/password authentication providers
>> > other than LDAP and AD.
>> >
>> > Cheers,
>> >
>> > Edgardo
>> >
>> > On Thu, Nov 19, 2015 at 5:31 PM, Joe Witt <jo...@gmail.com> wrote:
>> >
>> >> i conflated two different issues in my response so to clarify:
>> >>
>> >> I do not believe we're supporting basic authentication in our quest to
>> >> obtain user supplied identify information at this time.
>> >>
>> >> I do know that once we have that data we're delegating to an identity
>> >> login provider which we first have implemented to support AD/DS using
>> >> LDAP.
>> >>
>> >> The actual details available thus far are in the branch for NIFI-655
>> >> as found here [1] and the higher level description of the goal is
>> >> found here [2] but it is light on implementation details. Those are
>> >> better found in the JIRA for NIFI-655 it appears [3].
>> >>
>> >> [1] https://github.com/apache/nifi/tree/NIFI-655
>> >> [2]
>> >>
>> https://cwiki.apache.org/confluence/display/NIFI/Pluggable+Authentication
>> >> [3] https://issues.apache.org/jira/browse/NIFI-655
>> >>
>> >> Thanks
>> >> Joe
>> >>
>> >> On Thu, Nov 19, 2015 at 4:39 PM, Joe Witt <jo...@gmail.com> wrote:
>> >> > Edgardo
>> >> >
>> >> > We're tackling username and password based authentication in NIFI-655.
>> >> > It will not be utilizing/supporting basic authentication but perhaps
>> >> > you just mean uname/pword?
>> >> >
>> >> > The approach in NIFI-655 will delegate to a Directory Server/Active
>> >> Directory.
>> >> >
>> >> > Thanks
>> >> > Joe
>> >> >
>> >> > On Thu, Nov 19, 2015 at 3:58 PM, Edgardo Vega <edgardo.vega@gmail.com
>> >
>> >> wrote:
>> >> >> Wasn't there work being done on Basic Authentication? Just curious to
>> >> see
>> >> >> where that is along the development cycle.
>> >> >>
>> >> >> --
>> >> >> Cheers,
>> >> >>
>> >> >> Edgardo
>> >>
>> >
>> >
>> >
>> > --
>> > Cheers,
>> >
>> > Edgardo
>>
>
>
>
> --
> Cheers,
>
> Edgardo
Re: Basic Authentication
Posted by Andy LoPresto <al...@gmail.com>.
Hi Edgardo,
Can you confirm that I have the right understanding of what you are trying to do?
You have a public gateway using nginx. Nginx performs authentication using HTTP Basic Authentication against a file-based permissions store. You want nginx to add a header to the request which is forwarded to NiFi and this header value is checked to be used as an authentication token alongside the username.
If this is in fact what you are asking for, there would need to be changes made in NiFi to accept an arbitrary value as an authority provider response. With 0.4.0, we implemented JSON Web Tokens, or JWT (http://jwt.io), as a standard method for communicating identity information in the request header. NiFi issues these tokens after authenticating the user via client certificate or username/password authentication through an external identity provider (currently LDAP or AD, Kerberos in the future). If you were so inclined, you could probably implement a simple token issuer at the nginx point which contained a simple data store (username -> [password, token key]) and then generated and signed the JWT for the authenticated user and included it in the forwarded header. The NiFi instance would then validate and accept this token and treat the user as logged in and authorized.
NiFi currently uses a unique key per user in signing the tokens, so you would need to synchronize these keys with your custom token generator.
Please let me know if that helps answer your question.
Andy LoPresto
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69
> On Dec 14, 2015, at 10:38 AM, Edgardo Vega <ed...@gmail.com> wrote:
>
> Joe,
>
> I saw. I think its a big step forward. Our use case is that we are behind
> nginx who authenticates everyone. It would be great to allow a header to
> say that this is the user and they have been authenticated. Just a file
> based password user file would be okay with me something like htaccess.
> With these new changes I think it is very close. Great job.
>
> Cheers,
>
> Edgardo
>
> On Sun, Dec 13, 2015 at 10:21 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> Edgardo
>>
>> Be sure to check out the 0.4.0 release as it now supports
>> username/password authentication backed by active directory or
>> directory server via LDAP.
>>
>> Thanks
>> Joe
>>
>> On Fri, Nov 20, 2015 at 7:42 AM, Edgardo Vega <ed...@gmail.com>
>> wrote:
>>> Joe,
>>>
>>> Right now we currently proxy everything through nginx. Currently nginx
>> asks
>>> us for our username and password and then forwards the username and says
>>> they have been authentication. This works okay for nifi if all you want
>> to
>>> do is use the web interface. But there doesn't seem to be a way to make
>>> site to site work in this scenario. So we are trying to figure out how to
>>> secure nifi but not issue certs all over the place. We currently are
>> using
>>> site to site to get data from someone else as well as use it to send data
>>> to a few of our own mini clusters. Some of which are in different aws
>>> regions.
>>>
>>> Cheers,
>>>
>>> Edgardo
>>>
>>> On Fri, Nov 20, 2015 at 7:21 AM, Joe Witt <jo...@gmail.com> wrote:
>>>
>>>> Edgardo
>>>>
>>>> Yep. What are some others you'd be looking for? What we're basically
>>>> doing is preferring a delegated provider model. Kerberos is one we
>>>> plan to knock out as well
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Fri, Nov 20, 2015 at 7:10 AM, Edgardo Vega <ed...@gmail.com>
>>>> wrote:
>>>>> Joe,
>>>>>
>>>>> Yes I was looking for username and password. Seems like NIFI-655 will
>>>> setup
>>>>> the base to allow for other username/password authentication providers
>>>>> other than LDAP and AD.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Edgardo
>>>>>
>>>>> On Thu, Nov 19, 2015 at 5:31 PM, Joe Witt <jo...@gmail.com> wrote:
>>>>>
>>>>>> i conflated two different issues in my response so to clarify:
>>>>>>
>>>>>> I do not believe we're supporting basic authentication in our quest
>> to
>>>>>> obtain user supplied identify information at this time.
>>>>>>
>>>>>> I do know that once we have that data we're delegating to an identity
>>>>>> login provider which we first have implemented to support AD/DS using
>>>>>> LDAP.
>>>>>>
>>>>>> The actual details available thus far are in the branch for NIFI-655
>>>>>> as found here [1] and the higher level description of the goal is
>>>>>> found here [2] but it is light on implementation details. Those are
>>>>>> better found in the JIRA for NIFI-655 it appears [3].
>>>>>>
>>>>>> [1] https://github.com/apache/nifi/tree/NIFI-655
>>>>>> [2]
>>>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/NIFI/Pluggable+Authentication
>>>>>> [3] https://issues.apache.org/jira/browse/NIFI-655
>>>>>>
>>>>>> Thanks
>>>>>> Joe
>>>>>>
>>>>>> On Thu, Nov 19, 2015 at 4:39 PM, Joe Witt <jo...@gmail.com>
>> wrote:
>>>>>>> Edgardo
>>>>>>>
>>>>>>> We're tackling username and password based authentication in
>> NIFI-655.
>>>>>>> It will not be utilizing/supporting basic authentication but
>> perhaps
>>>>>>> you just mean uname/pword?
>>>>>>>
>>>>>>> The approach in NIFI-655 will delegate to a Directory Server/Active
>>>>>> Directory.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>> On Thu, Nov 19, 2015 at 3:58 PM, Edgardo Vega <
>> edgardo.vega@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>> Wasn't there work being done on Basic Authentication? Just
>> curious to
>>>>>> see
>>>>>>>> where that is along the development cycle.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Edgardo
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>>
>>>>> Edgardo
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>>
>>> Edgardo
>>
>
>
>
> --
> Cheers,
>
> Edgardo
Re: Basic Authentication
Posted by Matt Gilman <ma...@gmail.com>.
Edgardo,
The scenario you described is supported however you would need to use two
way ssl between nginx and NiFi. NiFi will consider a header but only when
the request comes from a trusted proxy. This would require the NiFi admin
to explicitly assign ROLE_PROXY to nginx. This way, when NiFi sees requests
from nginx, it knows it can use the value from the header as the actual end
user.
Matt
On Mon, Dec 14, 2015 at 1:38 PM, Edgardo Vega <ed...@gmail.com>
wrote:
> Joe,
>
> I saw. I think its a big step forward. Our use case is that we are behind
> nginx who authenticates everyone. It would be great to allow a header to
> say that this is the user and they have been authenticated. Just a file
> based password user file would be okay with me something like htaccess.
> With these new changes I think it is very close. Great job.
>
> Cheers,
>
> Edgardo
>
> On Sun, Dec 13, 2015 at 10:21 PM, Joe Witt <jo...@gmail.com> wrote:
>
> > Edgardo
> >
> > Be sure to check out the 0.4.0 release as it now supports
> > username/password authentication backed by active directory or
> > directory server via LDAP.
> >
> > Thanks
> > Joe
> >
> > On Fri, Nov 20, 2015 at 7:42 AM, Edgardo Vega <ed...@gmail.com>
> > wrote:
> > > Joe,
> > >
> > > Right now we currently proxy everything through nginx. Currently nginx
> > asks
> > > us for our username and password and then forwards the username and
> says
> > > they have been authentication. This works okay for nifi if all you want
> > to
> > > do is use the web interface. But there doesn't seem to be a way to make
> > > site to site work in this scenario. So we are trying to figure out how
> to
> > > secure nifi but not issue certs all over the place. We currently are
> > using
> > > site to site to get data from someone else as well as use it to send
> data
> > > to a few of our own mini clusters. Some of which are in different aws
> > > regions.
> > >
> > > Cheers,
> > >
> > > Edgardo
> > >
> > > On Fri, Nov 20, 2015 at 7:21 AM, Joe Witt <jo...@gmail.com> wrote:
> > >
> > >> Edgardo
> > >>
> > >> Yep. What are some others you'd be looking for? What we're basically
> > >> doing is preferring a delegated provider model. Kerberos is one we
> > >> plan to knock out as well
> > >>
> > >> Thanks
> > >> Joe
> > >>
> > >> On Fri, Nov 20, 2015 at 7:10 AM, Edgardo Vega <edgardo.vega@gmail.com
> >
> > >> wrote:
> > >> > Joe,
> > >> >
> > >> > Yes I was looking for username and password. Seems like NIFI-655
> will
> > >> setup
> > >> > the base to allow for other username/password authentication
> providers
> > >> > other than LDAP and AD.
> > >> >
> > >> > Cheers,
> > >> >
> > >> > Edgardo
> > >> >
> > >> > On Thu, Nov 19, 2015 at 5:31 PM, Joe Witt <jo...@gmail.com>
> wrote:
> > >> >
> > >> >> i conflated two different issues in my response so to clarify:
> > >> >>
> > >> >> I do not believe we're supporting basic authentication in our quest
> > to
> > >> >> obtain user supplied identify information at this time.
> > >> >>
> > >> >> I do know that once we have that data we're delegating to an
> identity
> > >> >> login provider which we first have implemented to support AD/DS
> using
> > >> >> LDAP.
> > >> >>
> > >> >> The actual details available thus far are in the branch for
> NIFI-655
> > >> >> as found here [1] and the higher level description of the goal is
> > >> >> found here [2] but it is light on implementation details. Those
> are
> > >> >> better found in the JIRA for NIFI-655 it appears [3].
> > >> >>
> > >> >> [1] https://github.com/apache/nifi/tree/NIFI-655
> > >> >> [2]
> > >> >>
> > >>
> >
> https://cwiki.apache.org/confluence/display/NIFI/Pluggable+Authentication
> > >> >> [3] https://issues.apache.org/jira/browse/NIFI-655
> > >> >>
> > >> >> Thanks
> > >> >> Joe
> > >> >>
> > >> >> On Thu, Nov 19, 2015 at 4:39 PM, Joe Witt <jo...@gmail.com>
> > wrote:
> > >> >> > Edgardo
> > >> >> >
> > >> >> > We're tackling username and password based authentication in
> > NIFI-655.
> > >> >> > It will not be utilizing/supporting basic authentication but
> > perhaps
> > >> >> > you just mean uname/pword?
> > >> >> >
> > >> >> > The approach in NIFI-655 will delegate to a Directory
> Server/Active
> > >> >> Directory.
> > >> >> >
> > >> >> > Thanks
> > >> >> > Joe
> > >> >> >
> > >> >> > On Thu, Nov 19, 2015 at 3:58 PM, Edgardo Vega <
> > edgardo.vega@gmail.com
> > >> >
> > >> >> wrote:
> > >> >> >> Wasn't there work being done on Basic Authentication? Just
> > curious to
> > >> >> see
> > >> >> >> where that is along the development cycle.
> > >> >> >>
> > >> >> >> --
> > >> >> >> Cheers,
> > >> >> >>
> > >> >> >> Edgardo
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Cheers,
> > >> >
> > >> > Edgardo
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers,
> > >
> > > Edgardo
> >
>
>
>
> --
> Cheers,
>
> Edgardo
>
Re: Basic Authentication
Posted by Edgardo Vega <ed...@gmail.com>.
Joe,
I saw. I think its a big step forward. Our use case is that we are behind
nginx who authenticates everyone. It would be great to allow a header to
say that this is the user and they have been authenticated. Just a file
based password user file would be okay with me something like htaccess.
With these new changes I think it is very close. Great job.
Cheers,
Edgardo
On Sun, Dec 13, 2015 at 10:21 PM, Joe Witt <jo...@gmail.com> wrote:
> Edgardo
>
> Be sure to check out the 0.4.0 release as it now supports
> username/password authentication backed by active directory or
> directory server via LDAP.
>
> Thanks
> Joe
>
> On Fri, Nov 20, 2015 at 7:42 AM, Edgardo Vega <ed...@gmail.com>
> wrote:
> > Joe,
> >
> > Right now we currently proxy everything through nginx. Currently nginx
> asks
> > us for our username and password and then forwards the username and says
> > they have been authentication. This works okay for nifi if all you want
> to
> > do is use the web interface. But there doesn't seem to be a way to make
> > site to site work in this scenario. So we are trying to figure out how to
> > secure nifi but not issue certs all over the place. We currently are
> using
> > site to site to get data from someone else as well as use it to send data
> > to a few of our own mini clusters. Some of which are in different aws
> > regions.
> >
> > Cheers,
> >
> > Edgardo
> >
> > On Fri, Nov 20, 2015 at 7:21 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> >> Edgardo
> >>
> >> Yep. What are some others you'd be looking for? What we're basically
> >> doing is preferring a delegated provider model. Kerberos is one we
> >> plan to knock out as well
> >>
> >> Thanks
> >> Joe
> >>
> >> On Fri, Nov 20, 2015 at 7:10 AM, Edgardo Vega <ed...@gmail.com>
> >> wrote:
> >> > Joe,
> >> >
> >> > Yes I was looking for username and password. Seems like NIFI-655 will
> >> setup
> >> > the base to allow for other username/password authentication providers
> >> > other than LDAP and AD.
> >> >
> >> > Cheers,
> >> >
> >> > Edgardo
> >> >
> >> > On Thu, Nov 19, 2015 at 5:31 PM, Joe Witt <jo...@gmail.com> wrote:
> >> >
> >> >> i conflated two different issues in my response so to clarify:
> >> >>
> >> >> I do not believe we're supporting basic authentication in our quest
> to
> >> >> obtain user supplied identify information at this time.
> >> >>
> >> >> I do know that once we have that data we're delegating to an identity
> >> >> login provider which we first have implemented to support AD/DS using
> >> >> LDAP.
> >> >>
> >> >> The actual details available thus far are in the branch for NIFI-655
> >> >> as found here [1] and the higher level description of the goal is
> >> >> found here [2] but it is light on implementation details. Those are
> >> >> better found in the JIRA for NIFI-655 it appears [3].
> >> >>
> >> >> [1] https://github.com/apache/nifi/tree/NIFI-655
> >> >> [2]
> >> >>
> >>
> https://cwiki.apache.org/confluence/display/NIFI/Pluggable+Authentication
> >> >> [3] https://issues.apache.org/jira/browse/NIFI-655
> >> >>
> >> >> Thanks
> >> >> Joe
> >> >>
> >> >> On Thu, Nov 19, 2015 at 4:39 PM, Joe Witt <jo...@gmail.com>
> wrote:
> >> >> > Edgardo
> >> >> >
> >> >> > We're tackling username and password based authentication in
> NIFI-655.
> >> >> > It will not be utilizing/supporting basic authentication but
> perhaps
> >> >> > you just mean uname/pword?
> >> >> >
> >> >> > The approach in NIFI-655 will delegate to a Directory Server/Active
> >> >> Directory.
> >> >> >
> >> >> > Thanks
> >> >> > Joe
> >> >> >
> >> >> > On Thu, Nov 19, 2015 at 3:58 PM, Edgardo Vega <
> edgardo.vega@gmail.com
> >> >
> >> >> wrote:
> >> >> >> Wasn't there work being done on Basic Authentication? Just
> curious to
> >> >> see
> >> >> >> where that is along the development cycle.
> >> >> >>
> >> >> >> --
> >> >> >> Cheers,
> >> >> >>
> >> >> >> Edgardo
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Cheers,
> >> >
> >> > Edgardo
> >>
> >
> >
> >
> > --
> > Cheers,
> >
> > Edgardo
>
--
Cheers,
Edgardo