nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy LoPresto <alopre...@apache.org>
Subject Re: Access policies
Date Sat, 25 Feb 2017 01:32:15 GMT
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Feb 24, 2017, at 10:38 AM, Bryan Bende <bbende@gmail.com> 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 <mark.o.bean@gmail.com> 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 <bbende@gmail.com> 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 <mark.o.bean@gmail.com>
>> 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 <matt.c.gilman@gmail.com
>>> 
>>>> 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 <mark.o.bean@gmail.com>
>>> 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


Mime
View raw message