I don't have a Ranger instance at the moment to test, but the "deny"
policy may work.

Regarding the "Allow Anonymous" approach... since it is a function of
the Authorizer, I think it needs to be in the config in
authorizers.xml. Maybe there is a way to make it applicable to all
authorizers by checking for it in some common code before calling the
underlying authorizer.

The file-based authorizer would never have this problem since it
doesn't provide any wild-carding concepts, so the only way an
anonymous user would get authorized is if you explicitly created a
user called "anonymous" and put that user in the policy for "/flow".


On Mon, Apr 9, 2018 at 11:57 AM, Kevin Doran <kdo...@apache.org> wrote:
> Good catch, Bryan. It does sound like that could explain what is going on in 
> these cases.
>
> Regarding  this:
>
>>    I think one way to support this might be to bring back the "Allow
>>    Anonymous" flag in the Ranger Authorizer config.
>>
>>    This way if this value is set to false, then before doing anything
>>    else the authorizer would check if the incoming identity is
>>    "anonymous" and reject the request before even checking the actual
>>    policies from Ranger.
>
> Would this be a good setting to have in general, perhaps for managed 
> authorizer or in nifi.properties, so that it could be toggled for any 
> configured authorizer?
>
> ´╗┐On 4/9/18, 11:32, "Bryan Bende" <bbe...@gmail.com> wrote:
>
>     Actually, thinking about this more, I think the issue is that you
>     currently can't use Ranger's {USER} concept because NiFi always has an
>     "anonymous" user, and there is no way in Ranger to exclude "anonymous"
>     from {USER}.
>
>     What is happening is something like this...
>
>     - You enter the NiFi URL in your browser which loads some of the 
> front-end code
>     - The front-end code then attempts to access a server side resource
>     that requires authorization
>     - This request is happening as the anonymous user, and if it fails
>     with an unauthorized response, then the front-end knows to present the
>     login page
>     - In this case, the request is succeeding because of the policy you
>     have with {USER}
>
>     I think one way to support this might be to bring back the "Allow
>     Anonymous" flag in the Ranger Authorizer config.
>
>     This way if this value is set to false, then before doing anything
>     else the authorizer would check if the incoming identity is
>     "anonymous" and reject the request before even checking the actual
>     policies from Ranger.
>
>     On Mon, Apr 9, 2018 at 11:10 AM, Bryan Bende <bbe...@gmail.com> wrote:
>     > Ok, so you end up in the NiFi UI with the identity in the top right
>     > saying "Anonymous user" ? (as show in the screenshots of that hwx
>     > forum)
>     >
>     > I think we need to dig into what is happening during authentication...
>     >
>     > Can you do a fresh login to NiFi using your LDAP credentials, and then
>     > capture the content from nifi-user.log that occurred during this
>     > login?
>     >
>     >
>     > On Mon, Apr 9, 2018 at 10:37 AM, Meixner, Johannes
>     > <johan...@perceivon.net> wrote:
>     >>> If so, then how are you authenticating to NiFi as an "anonymous" user?
>     >>
>     >> Good question. NiFi uses its LdapProvider (with Authentication 
> Strategy =
>     >> SIMPLE, Identity Strategy = USE_USERNAME) to identify and the
>     >> RangerNifiAuthorizer to authorise users.
>     >>
>     >> I'm not quite sure yet what authenticates the anonymous user, but I've 
> found
>     >> similar reports in a Hortonworks thread [1] without obvious solution.
>     >>
>     >> [1]
>     >> 
> https://community.hortonworks.com/questions/142667/how-to-give-permissions-to-users-to-access-nifi-ui.html
>     >>
>     >> On Mon, Apr 9, 2018 at 4:09 PM, Bryan Bende <bbe...@gmail.com> wrote:
>     >>>
>     >>> Ah thanks for the info, didn't know that.
>     >>>
>     >>> So you have a policy in Ranger where the resource is "/flow", the
>     >>> action is READ, and the users/groups is "{USER}", and then you are
>     >>> saying an "anonymous" user can retrieve the flow?
>     >>>
>     >>> I'm assuming that since your Ranger is backed by an LDAP, that you
>     >>> also have configured NiFi's LDAP Login Identity Provider?
>     >>>
>     >>> If so, then how are you authenticating to NiFi as an "anonymous" user?
>     >>>
>     >>> In a secure NiFi you should always have to authenticate as some
>     >>> identity, the anonymous user is only used in an unsecured NiFi when
>     >>> there is not authentication/authorization taking place.
>     >>>
>     >>>
>     >>> On Mon, Apr 9, 2018 at 9:51 AM, Meixner, Johannes
>     >>> <johan...@perceivon.net> wrote:
>     >>> > Hi Bryan,
>     >>> >
>     >>> > It's a placeholder in Ranger for usernames, see
>     >>> >
>     >>> > 
> https://cwiki.apache.org/confluence/display/RANGER/Support+for+%24username+variable
>     >>> >
>     >>> > which is used by certain matcher classes.
>     >>> >
>     >>> > On Mon, Apr 9, 2018 at 3:28 PM, Bryan Bende <bbe...@gmail.com> 
> wrote:
>     >>> >>
>     >>> >> Hello,
>     >>> >>
>     >>> >> I don't see any issue with the code you linked to. It's saying "if 
> the
>     >>> >> ranger policies say the operation is allowed, then return 
> approved".
>     >>> >>
>     >>> >> Is '{USER}' a special syntax in Ranger? or are you using that as a
>     >>> >> placeholder in email so you don't have to provide the real user
>     >>> >> identity?
>     >>> >>
>     >>> >> I haven't seen that syntax before so just trying to understand what
>     >>> >> {USER} and {OWNER} mean here.
>     >>> >>
>     >>> >> -Bryan
>     >>> >>
>     >>> >>
>     >>> >> On Mon, Apr 9, 2018 at 3:55 AM, Meixner, Johannes
>     >>> >> <johan...@perceivon.net> wrote:
>     >>> >> > I'm trying to harden my NiFi instance's authorizations and 
> auditing
>     >>> >> > using
>     >>> >> > Ranger (which is backed by an LDAP instance).
>     >>> >> >
>     >>> >> > In Ranger I have defined a couple of resources defined to be
>     >>> >> > authorized
>     >>> >> > for
>     >>> >> > the nifi nodes' CNs (from SSL certs), `{USER}` and `{OWNER}`.
>     >>> >> >
>     >>> >> > Turns out that if I add `{USER}` to the resource containing 
> "/flow" I
>     >>> >> > can
>     >>> >> > read the flow as anonymous user, which is exactly the opposite of
>     >>> >> > what I
>     >>> >> > want.
>     >>> >> >
>     >>> >> > Some digging last week lead me to believe that this is due to 
> the way
>     >>> >> > RangerNiFiAuthorizer.java [1] does authorizations. Note, I could 
> be
>     >>> >> > on
>     >>> >> > the
>     >>> >> > completely wrong track here.
>     >>> >> >
>     >>> >> > Is there any way to prevent `anonymous` from doing anything in 
> NiFi,
>     >>> >> > through Ranger?
>     >>> >> >
>     >>> >> > Best regards
>     >>> >> > Johannes Meixner
>     >>> >> >
>     >>> >> >
>     >>> >> > [1]
>     >>> >> >
>     >>> >> >
>     >>> >> > 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-ranger-bundle/nifi-ranger-plugin/src/main/java/org/apache/nifi/ranger/authorization/RangerNiFiAuthorizer.java#L185-L188
>     >>> >
>     >>> >
>     >>
>     >>
>
>
>

Reply via email to