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
<http://openid.net/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?
>

Reply via email to