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?

Reply via email to