White space was the problem. The user string specified when adding the user to NiFi did not contain whitespaces whereas the certificate does include whitespaces.
What is interesting is that the authentication passed successfully. Apparently, the certificate authentication process ignores whitespace and is case-insensitive. NiFi does evaluate whitespace (and maybe case too; I haven't confirmed that one yet.) Is this an enhancement to be added? Can NiFi be made to ignore whitespace and be case-insensitive for usernames? It doesn't seem it's bending or breaking authentication since that passes either way. This is simply a NiFi-ism in comparing string values of users. On Fri, Feb 24, 2017 at 1:06 PM, Bryan Bende <[email protected]> wrote: > Mark, > > How are users authenticating to the NiFi? > > Also, are you sure "UserX" in the logs is the exact username in NiFi > of the user you gave access to view the user interface? > > The identity has to match exactly, so a common issue is a minor > whitespace or something making it not line up, like "CN=UserX, > OU=MyOrg" with a space coming from a cert vs. "CN=UserX,OU=MyOrg" with > no space entered in NiFi. > > Thanks, > > Bryan > > On Fri, Feb 24, 2017 at 12:58 PM, Mark Bean <[email protected]> wrote: > > Your description is exactly how I would expect things to work. However, > the > > user is not able to access the graph. > > > > The nifi-user.log indicates: > > > > o.a.n.w.s.NiFiAuthenticationFilter Attempting request for (<UserX>) GET > > https://<nifi-url>/nifi-api/flow/current-user > > o.a.n.w.s.NiFiAuthenticationFilter Authentication success for <UserX> > > o.a.n.w.a.c.AccessDeniedExceptionMapper <UserX> does not have > permission to > > access the requested resource. Returning Forbidden response. > > > > > > > > On Fri, Feb 24, 2017 at 12:46 PM, Matt Gilman <[email protected]> > > wrote: > > > >> Mark, > >> > >> Adding the user and then granting that user permissions to 'view the > user > >> interface' is all that is required for the user to access the UI. If you > >> check out the nifi-user.log you should be able to see which request > failed. > >> In the coming 1.2.0 release, we've made the authorization error messages > >> more meaningful which should make it easier to see which policies the > user > >> is lacking. > >> > >> Subsequently, the user can be granted to various parts of data flow > >> (through the policies access from the canvas Operate palette). This will > >> allow the user to see the types/configuration of various components > and/or > >> modify them. Without these permissions, the user can still see the data > >> flow but they will not be able to see details of those components. > >> > >> Matt > >> > >> On Fri, Feb 24, 2017 at 12:32 PM, Mark Bean <[email protected]> > wrote: > >> > >> > I am attempting to apply Access Policies appropriately. As a very > first > >> > step, I want to grant a user access to the UI. From the global menu, I > >> > chose Users and added the user. Then, again from the global menu, I > chose > >> > Policies. I added the user to "view the user interface" and "access > the > >> > controller" ("view" only; not "modify"). > >> > > >> > When this failed to give the user access, I went to the component > level > >> > policy at the root of the graph (i.e. "NiFi Flow" process group). I > >> granted > >> > "view the component". > >> > > >> > With the above policies, the user receives a message that states > "Unable > >> to > >> > perform the desired action due to insufficient permissions. Contact > the > >> > system administrator." > >> > > >> > How do I grant a user access to the UI? > >> > > >> > The Admin Guide has a section on Access Policy Configuration Examples. > >> > However, it begins with "The following scenarios assume User1 is an > >> > administrator and User2 is a newly added user that has only been given > >> > access to the UI." Suggestion: create a new example scenario which > >> > demonstrates "has been given access to the UI". > >> > > >> > Thanks, > >> > Mark > >> > > >> >
