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
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On May 17, 2018, at 7:39 AM, Bryan Bende <bbe...@gmail.com> 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 <helloj...@gmail.com> 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 <bbe...@gmail.com> 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 <helloj...@gmail.com>
>>> 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 <apere...@gmail.com>
>>>> 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 <helloj...@gmail.com>
>>>>> 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?

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to