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?
