Re: Allowing all users to connect

[Andy LoPresto]

Juan,

In your case it may also make sense to implement a simple custom authenticator 
that just checks that the certificate has a certain identifier (in the DN or 
OID, etc.) and is signed by a specific certificate. You don’t care so much 
about the individual identity of the user, but rather the fact that they 
possess a piece of information signaling that they belong to the approved group.

For more fine-grained control, you will definitely want to examine the 
individual user authentication and authorization, but to deploy in a scenario 
where you know you will have *N* valid users, those identities are not known a 
priori, but each has a valid certificate (token), this looks like it would 
work. You can also implement accepted user lists (preferred) or excluded user 
lists (fallback) as restricting behaviors if a specific certificate needs to be 
revoked / user lose access without blocking all remaining users.


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On May 17, 2018, at 7:39 AM, Bryan Bende  wrote:
> 
> Well you have to separate the concepts of authentication and authorization...
> 
> The stuff you just highlighted from the admin guide is referring to
> authentication options, which is how you identify a user is who they
> say they are.
> 
> After authentication you then have a user identity that you need to authorize.
> 
> In most cases you probably would use LDAP for authentication and also
> use the LDAP user-group-provider for authorization, but technically
> that doesn't have to be the case.
> 
> On Thu, May 17, 2018 at 10:27 AM, Juan Sequeiros  wrote:
>> oooh ok I just assumed that if using LDAP then they have to use username /
>> password based on this from admin guide:
>> 
>> " NiFi supports user authentication via client certificates, via
>> username/password, via Apache Knox, or via OpenId Connect.
>> 
>> Username/password authentication is performed by a 'Login Identity
>> Provider'. The Login Identity Provider is a pluggable mechanism for
>> authenticating users via their username/password. Which Login Identity
>> Provider to use is configured in the nifi.properties file. Currently NiFi
>> offers username/password with Login Identity Providers options for LDAP and
>> Kerberos."
>> 
>> 
>> On Thu, May 17, 2018 at 10:21 AM Bryan Bende  wrote:
>>> 
>>> It really comes down to how you want to configure the authorizer...
>>> 
>>> An authorizer is made up of a user-group-provider and a policy-provider.
>>> 
>>> The user-group-provider can be file-based, ldap, composite
>>> (combination of multiple), or custom if you implement your own.
>>> 
>>> The policy provider can be file-based, ranger, or composite.
>>> 
>>> If you are issuing client certs to users for authentication, then I
>>> see two main options for authorization...
>>> 
>>> 1) Use file-based for both providers, in which case you define an
>>> initial admin and the admin has to go in and manually create all the
>>> users, or create them as people join the team.
>>> 
>>> 2) Setup an LDAP, or connect to an existing one, that has all the user
>>> identities... then use the LDAP user-group-provider, so you won't have
>>> to define any users in NiFi because they are already in LDAP. You
>>> would still have to define policies, but assuming you can put all the
>>> users in a group in ldap, you could just create one policy that gives
>>> the group access to the root canvas.
>>> 
>>> 
>>> On Thu, May 17, 2018 at 10:06 AM, Juan Sequeiros 
>>> wrote:
 Thanks, Andrew / Bryan.
 Yeah this right now is a prototype with a team of about 10 people.
 
 We all have certs that we've self-signed.
 
 I've not messed with this that much but if I want to use certs it seems
 the
 user set up in the initial admin section will have to the other user
 creations.
 
 More down the line if this prototype is released and without knowing
 their
 PKI infrastructure I am wondering how to make user authorization as
 painless
 as possible without knowing the technical background of the "admins" of
 this
 prototype product.
 
 As it is now granted I've not worked with this piece much, Someone needs
 to
 set up an initial admin > connect > grant permissions to initial admin.
 Then I will have to proactively know who else needs access and add them,
 currently looking through the UI but presume this can be automated
 through
 API, will look at NiPy for that.
 
 
 On Thu, May 17, 2018 at 8:40 AM Andrew Grande 
 wrote:
> 
> Juan,
> 
> A cert implies one knows the identity of the cert holder.
> 
> I'd imagine if you shared it with multiple users, you would have
> achieved
> this semi-anonymous requirement.
> 
> I would take a really deep 

Re: Allowing all users to connect

[Bryan Bende]

Well you have to separate the concepts of authentication and authorization...

The stuff you just highlighted from the admin guide is referring to
authentication options, which is how you identify a user is who they
say they are.

After authentication you then have a user identity that you need to authorize.

In most cases you probably would use LDAP for authentication and also
use the LDAP user-group-provider for authorization, but technically
that doesn't have to be the case.

On Thu, May 17, 2018 at 10:27 AM, Juan Sequeiros  wrote:
> oooh ok I just assumed that if using LDAP then they have to use username /
> password based on this from admin guide:
>
> " NiFi supports user authentication via client certificates, via
> username/password, via Apache Knox, or via OpenId Connect.
>
> Username/password authentication is performed by a 'Login Identity
> Provider'. The Login Identity Provider is a pluggable mechanism for
> authenticating users via their username/password. Which Login Identity
> Provider to use is configured in the nifi.properties file. Currently NiFi
> offers username/password with Login Identity Providers options for LDAP and
> Kerberos."
>
>
> On Thu, May 17, 2018 at 10:21 AM Bryan Bende  wrote:
>>
>> It really comes down to how you want to configure the authorizer...
>>
>> An authorizer is made up of a user-group-provider and a policy-provider.
>>
>> The user-group-provider can be file-based, ldap, composite
>> (combination of multiple), or custom if you implement your own.
>>
>> The policy provider can be file-based, ranger, or composite.
>>
>> If you are issuing client certs to users for authentication, then I
>> see two main options for authorization...
>>
>> 1) Use file-based for both providers, in which case you define an
>> initial admin and the admin has to go in and manually create all the
>> users, or create them as people join the team.
>>
>> 2) Setup an LDAP, or connect to an existing one, that has all the user
>> identities... then use the LDAP user-group-provider, so you won't have
>> to define any users in NiFi because they are already in LDAP. You
>> would still have to define policies, but assuming you can put all the
>> users in a group in ldap, you could just create one policy that gives
>> the group access to the root canvas.
>>
>>
>> On Thu, May 17, 2018 at 10:06 AM, Juan Sequeiros 
>> wrote:
>> > Thanks, Andrew / Bryan.
>> > Yeah this right now is a prototype with a team of about 10 people.
>> >
>> > We all have certs that we've self-signed.
>> >
>> > I've not messed with this that much but if I want to use certs it seems
>> > the
>> > user set up in the initial admin section will have to the other user
>> > creations.
>> >
>> > More down the line if this prototype is released and without knowing
>> > their
>> > PKI infrastructure I am wondering how to make user authorization as
>> > painless
>> > as possible without knowing the technical background of the "admins" of
>> > this
>> > prototype product.
>> >
>> > As it is now granted I've not worked with this piece much, Someone needs
>> > to
>> > set up an initial admin > connect > grant permissions to initial admin.
>> > Then I will have to proactively know who else needs access and add them,
>> > currently looking through the UI but presume this can be automated
>> > through
>> > API, will look at NiPy for that.
>> >
>> >
>> > On Thu, May 17, 2018 at 8:40 AM Andrew Grande 
>> > wrote:
>> >>
>> >> Juan,
>> >>
>> >> A cert implies one knows the identity of the cert holder.
>> >>
>> >> I'd imagine if you shared it with multiple users, you would have
>> >> achieved
>> >> this semi-anonymous requirement.
>> >>
>> >> I would take a really deep look into why you want to do it this way,
>> >> though. Defeats the purpose of security. Is there a problem issuing
>> >> client
>> >> certificates?
>> >>
>> >>
>> >> Andrew
>> >>
>> >> On Wed, May 16, 2018, 9:50 PM Juan Sequeiros 
>> >> wrote:
>> >>>
>> >>> Hello all,
>> >>>
>> >>> Is there a way I can set up authorization to secured UI to anyone who
>> >>> has
>> >>> a valid cert with out knowing who they will be?

Re: Allowing all users to connect

[Juan Sequeiros]

oooh ok I just assumed that if using LDAP then they have to use username /
password based on this from admin guide:

" NiFi supports user authentication via client certificates, via
username/password, via Apache Knox, or via OpenId Connect
.

Username/password authentication is performed by a 'Login Identity
Provider'. The Login Identity Provider is a pluggable mechanism for
authenticating users via their username/password. *Which Login Identity
Provider to use is configured in the nifi.properties file. Currently NiFi
offers username/password with Login Identity Providers options for LDAP and
Kerberos."*

On Thu, May 17, 2018 at 10:21 AM Bryan Bende  wrote:

> It really comes down to how you want to configure the authorizer...
>
> An authorizer is made up of a user-group-provider and a policy-provider.
>
> The user-group-provider can be file-based, ldap, composite
> (combination of multiple), or custom if you implement your own.
>
> The policy provider can be file-based, ranger, or composite.
>
> If you are issuing client certs to users for authentication, then I
> see two main options for authorization...
>
> 1) Use file-based for both providers, in which case you define an
> initial admin and the admin has to go in and manually create all the
> users, or create them as people join the team.
>
> 2) Setup an LDAP, or connect to an existing one, that has all the user
> identities... then use the LDAP user-group-provider, so you won't have
> to define any users in NiFi because they are already in LDAP. You
> would still have to define policies, but assuming you can put all the
> users in a group in ldap, you could just create one policy that gives
> the group access to the root canvas.
>
>
> On Thu, May 17, 2018 at 10:06 AM, Juan Sequeiros 
> wrote:
> > Thanks, Andrew / Bryan.
> > Yeah this right now is a prototype with a team of about 10 people.
> >
> > We all have certs that we've self-signed.
> >
> > I've not messed with this that much but if I want to use certs it seems
> the
> > user set up in the initial admin section will have to the other user
> > creations.
> >
> > More down the line if this prototype is released and without knowing
> their
> > PKI infrastructure I am wondering how to make user authorization as
> painless
> > as possible without knowing the technical background of the "admins" of
> this
> > prototype product.
> >
> > As it is now granted I've not worked with this piece much, Someone needs
> to
> > set up an initial admin > connect > grant permissions to initial admin.
> > Then I will have to proactively know who else needs access and add them,
> > currently looking through the UI but presume this can be automated
> through
> > API, will look at NiPy for that.
> >
> >
> > On Thu, May 17, 2018 at 8:40 AM Andrew Grande 
> wrote:
> >>
> >> Juan,
> >>
> >> A cert implies one knows the identity of the cert holder.
> >>
> >> I'd imagine if you shared it with multiple users, you would have
> achieved
> >> this semi-anonymous requirement.
> >>
> >> I would take a really deep look into why you want to do it this way,
> >> though. Defeats the purpose of security. Is there a problem issuing
> client
> >> certificates?
> >>
> >>
> >> Andrew
> >>
> >> On Wed, May 16, 2018, 9:50 PM Juan Sequeiros 
> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> Is there a way I can set up authorization to secured UI to anyone who
> has
> >>> a valid cert with out knowing who they will be?
>

Re: Allowing all users to connect

[Bryan Bende]

It really comes down to how you want to configure the authorizer...

An authorizer is made up of a user-group-provider and a policy-provider.

The user-group-provider can be file-based, ldap, composite
(combination of multiple), or custom if you implement your own.

The policy provider can be file-based, ranger, or composite.

If you are issuing client certs to users for authentication, then I
see two main options for authorization...

1) Use file-based for both providers, in which case you define an
initial admin and the admin has to go in and manually create all the
users, or create them as people join the team.

2) Setup an LDAP, or connect to an existing one, that has all the user
identities... then use the LDAP user-group-provider, so you won't have
to define any users in NiFi because they are already in LDAP. You
would still have to define policies, but assuming you can put all the
users in a group in ldap, you could just create one policy that gives
the group access to the root canvas.


On Thu, May 17, 2018 at 10:06 AM, Juan Sequeiros  wrote:
> Thanks, Andrew / Bryan.
> Yeah this right now is a prototype with a team of about 10 people.
>
> We all have certs that we've self-signed.
>
> I've not messed with this that much but if I want to use certs it seems the
> user set up in the initial admin section will have to the other user
> creations.
>
> More down the line if this prototype is released and without knowing their
> PKI infrastructure I am wondering how to make user authorization as painless
> as possible without knowing the technical background of the "admins" of this
> prototype product.
>
> As it is now granted I've not worked with this piece much, Someone needs to
> set up an initial admin > connect > grant permissions to initial admin.
> Then I will have to proactively know who else needs access and add them,
> currently looking through the UI but presume this can be automated through
> API, will look at NiPy for that.
>
>
> On Thu, May 17, 2018 at 8:40 AM Andrew Grande  wrote:
>>
>> Juan,
>>
>> A cert implies one knows the identity of the cert holder.
>>
>> I'd imagine if you shared it with multiple users, you would have achieved
>> this semi-anonymous requirement.
>>
>> I would take a really deep look into why you want to do it this way,
>> though. Defeats the purpose of security. Is there a problem issuing client
>> certificates?
>>
>>
>> Andrew
>>
>> On Wed, May 16, 2018, 9:50 PM Juan Sequeiros  wrote:
>>>
>>> Hello all,
>>>
>>> Is there a way I can set up authorization to secured UI to anyone who has
>>> a valid cert with out knowing who they will be?

Re: Allowing all users to connect

[Juan Sequeiros]

Thanks, Andrew / Bryan.
Yeah this right now is a prototype with a team of about 10 people.

We all have certs that we've self-signed.

I've not messed with this that much but if I want to use certs it seems the
user set up in the initial admin section will have to the other user
creations.

More down the line if this prototype is released and without knowing their
PKI infrastructure I am wondering how to make user authorization as
painless as possible without knowing the technical background of the
"admins" of this prototype product.

As it is now granted I've not worked with this piece much, Someone needs to
set up an initial admin > connect > grant permissions to initial admin.
Then I will have to proactively know who else needs access and add them,
currently looking through the UI but presume this can be automated through
API, will look at NiPy for that.


On Thu, May 17, 2018 at 8:40 AM Andrew Grande  wrote:

> Juan,
>
> A cert implies one knows the identity of the cert holder.
>
> I'd imagine if you shared it with multiple users, you would have achieved
> this semi-anonymous requirement.
>
> I would take a really deep look into why you want to do it this way,
> though. Defeats the purpose of security. Is there a problem issuing client
> certificates?
>
>
> Andrew
>
> On Wed, May 16, 2018, 9:50 PM Juan Sequeiros  wrote:
>
>> Hello all,
>>
>> Is there a way I can set up authorization to secured UI to anyone who has
>> a valid cert with out knowing who they will be?
>>
>

NiFi Test Harness Proof-of-Concept

[Horváth Péter Gergely]

Dear All,

In the past, I had some cases when testing a complex NiFi flow became a
tedious manual exercise: that's where the idea came that maybe it would be
possible to automate these steps somehow.

I have developed a small sample NiFi test harness that allows you to
install a NiFi flow to a test NiFi instance and finally, I've managed to
push the sample through our company's open sourcing process.

The repository is available on GitHub: https://github.com/Thi
nkBigAnalytics/nifi-test

The proof-of-concept demonstrates two possible approaches:
 - NiFiFlowTest [1] demonstrates a solution where a processor's properties
are re-written before the test is performed, allowing some mock source
service to be used.
 - NiFiMockFlowTest [2] demonstrates how a processor in the flow could be
replaced and mocked by a custom class.

There are some limitations, for example, detecting if NiFi is up and running
 [3], but generally speaking, the concept seems to be usable.

If you think this sample would be helpful for you, please give it a try:
I'm happy to receive feedback as well.

I am wondering if there is someone who would be willing to enhance the
solution further, or even merge some re-usable parts into the NiFi code
base.

Thanks,
Peter

[1] https://github.com/ThinkBigAnalytics/nifi-test/
blob/master/src/test/java/com/thinkbiganalytics/nifi/test/NiFiFlowTest.java
[2] https://github.com/ThinkBigAnalytics/nifi-test/
blob/master/src/test/java/com/thinkbiganalytics/nifi/test/
NiFiMockFlowTest.java
[3] https://github.com/ThinkBigAnalytics/nifi-test/
blob/master/src/main/java/com/thinkbiganalytics/nifitest/
TestNiFiInstance.java#L206

Re: Allowing all users to connect

[Andrew Grande]

Juan,

A cert implies one knows the identity of the cert holder.

I'd imagine if you shared it with multiple users, you would have achieved
this semi-anonymous requirement.

I would take a really deep look into why you want to do it this way,
though. Defeats the purpose of security. Is there a problem issuing client
certificates?

Andrew

On Wed, May 16, 2018, 9:50 PM Juan Sequeiros  wrote:

> Hello all,
>
> Is there a way I can set up authorization to secured UI to anyone who has
> a valid cert with out knowing who they will be?
>

Re: Allowing all users to connect

[Bryan Bende]

You could create an identity mapping in nifi.properties that maps any cert
DN to a hard coded user identity, say “nifi-user”, so every user looks like
that one user.

You would lose ability to track which users changed the flow, but I’m
guessing that’s not important if you want to give everyone access.

On Wed, May 16, 2018 at 9:50 PM Juan Sequeiros  wrote:

> Hello all,
>
> Is there a way I can set up authorization to secured UI to anyone who has
> a valid cert with out knowing who they will be?
>
-- 
Sent from Gmail Mobile