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
> 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>
>> > 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?