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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> > 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 < > [email protected] > >> > > >> >> 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
