You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Mark Bean <ma...@gmail.com> on 2017/02/24 17:32:54 UTC
Access policies
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
Re: Access policies
Posted by Andy LoPresto <al...@apache.org>.
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 <bb...@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 <ma...@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 <bb...@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 <ma...@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 <ma...@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
Re: Access policies
Posted by Bryan Bende <bb...@gmail.com>.
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 <ma...@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 <bb...@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 <ma...@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 <ma...@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
Re: Access policies
Posted by Mark Bean <ma...@gmail.com>.
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 <bb...@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 <ma...@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 <ma...@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 <ma...@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
> >> >
> >>
>
Re: Access policies
Posted by Bryan Bende <bb...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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
>> >
>>
Re: Access policies
Posted by Mark Bean <ma...@gmail.com>.
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 <ma...@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 <ma...@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
> >
>
Re: Access policies
Posted by Matt Gilman <ma...@gmail.com>.
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 <ma...@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
>