To follow up on what Bryan explained, the authentication has nothing to do with the whitespace parsing in String comparisons because it evaluates the signature on the presented client certificate. That signature is generated from the private key of the CA (certificate authority) that issued the client certificate. The subject DN could be anything “CN=lots of spaces” and it would have no impact. (Remember, authentication is proving that an entity is the identity they claim).
When the “user” logical entity is created in NiFi and an administrator provides the identity string to authorize, this must be character-by-character identical with the DN of the presented certificate. Otherwise, it opens up the possibility of escalation of privilege attacks. Imagine two certificates signed by “Global CA”, which is listed as a trusted CA cert in the NiFi truststore: “CN=alopresto,OU=Apache NiFi” and “CN=alopresto, OU=Apache NiFi”. While a person may see those strings and assume they are identical, one could have been issued to me, and another to my sister Alexa. We are not the same person and it is unlikely we have identical permissions in the system (even if we did, we want to track our actions as individuals for auditing, etc.). Authorization is proving that an established identity has permission to perform whatever action they are trying to undertake. In NiFi, authentication and authorization are strictly separate concerns, allowing us to provide pluggable solutions, such as client certificates, LDAP, or Kerberos for authentication and file-based or Apache Ranger-based authorization without impacting the other. Even a “useful” error message like the following is not a good idea (assume the entered identity string is “CN=alopresto, OU=Apache NiFi” with a space): >>>> o.a.n.w.s.NiFiAuthenticationFilter Attempting request for >>>> (CN=alopresto,OU=Apache NiFi) GET >>>> https://<nifi-url>/nifi-api/flow/current-user >>>> o.a.n.w.s.NiFiAuthenticationFilter Authentication success for >>>> CN=alopresto,OU=Apache NiFi >>>> o.a.n.w.a.c.AccessDeniedExceptionMapper CN=alopresto,OU=Apache NiFi does >>>> not have permission to access the requested resource. Returning Forbidden >>>> response. (Did you mean CN=alopresto, OU=Apache NiFi ?) This provides an attack vector for an enumeration attack, where anyone with a certificate signed by any trusted issuer can start to discover the users that exist in the system and that are authorized to access certain elements. At this time, careful manual examination of the failed credentials in the case of an error is our best tool to solve this problem. We are trying to improving the situation and are open to suggestions if you have an idea of what would be clearer to you when you encounter this situation. Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Feb 24, 2017, at 10:38 AM, Bryan Bende <[email protected]> wrote: > > Glad to hear it was a simple white-space issue. > > The authentication process is simply looking at the client certificate and > verifying it came from trusted certificate authority, then it extracts the > DN and passes it along as the identity for authorization. So that is why > authentication succeeds. The users entered in NiFi only come into play in > the second phase during authorization. > > > On Fri, Feb 24, 2017 at 1:31 PM Mark Bean <[email protected]> wrote: > >> 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 >>>>>> >>>>> >>> >> > -- > Sent from Gmail Mobile
signature.asc
Description: Message signed with OpenPGP using GPGMail
