NIFI-1733 Adding a Ranger implementation of NiFi's Authorizer API

[bbende]

This PR adds an Authorizer implementation that uses Apache Ranger and also modifies the build so that Ranger related artifacts are only included when using -Pinclude-ranger, this way the normal build does not need to include anything related to Ranger, and those that want it can also easily build it themselves.

When using NiFi with Ranger you would declare an Authorizer like the following in authorizers.xml:

    <authorizer>
        <identifier>ranger-provider</identifier>
        <class>org.apache.nifi.ranger.authorization.RangerNiFiAuthorizer</class>
        <property name="Ranger Audit Config Path">src/test/resources/ranger/ranger-nifi-audit.xml</property>
        <property name="Ranger Security Config Path">src/test/resources/ranger/ranger-nifi-security.xml</property>
        <property name="Ranger Service Type">nifi</property>
        <property name="Ranger Application Id">nifi</property>
        <property name="Ranger Admin Identity">CN=ranger-admin, OU=Apache Ranger, O=Apache, L=Santa Monica, ST=CA, C=US</property>
        <property name="Ranger Kerberos Enabled">false</property>
    </authorizer>

For anyone interested in playing around with this, I created a Vagrant VM that can run a build of Ranger:
https://github.com/bbende/apache-ranger-vagrant

[joewitt]

@bbende really nice job on the licensing stuff and thanks for finding/fixing the lgpl findbugs annotations issue!

[YolandaMDavis]

@bbende happy to take this on for review. Please update with the latest to resolve conflicts.

[YolandaMDavis]

Could not see testing coverage in this area, especially in the case where kerberos is enabled but no kerberos properties (keytab/principal) exist.

[bbende]

Good call, working on some unit tests now for these scenarios

[YolandaMDavis]

@bbende overall looks great ! I executed unit tests for coverage evaluation (hence my notes above) and did some integration testing with a remote Ranger server which also worked well.

In looking at the RangerBasePluginWithPolicies it appeared to me to be a convenience class for extracting resources and storing a copy of the resource value for lookup later. One thought I had was whether the RangerPolicyEngine could be interrogated (via methods on the RangerBasePlugin) to check for existing resources to avoid the copy?

[bbende]

@YolandaMDavis thanks for reviewing! Working on some changes based on your feedback.

Regarding the need for RangerBasePluginWithPolicies... unfortunately the PolicyEngine is a private member variable of RangerBasePlugin and there is no getter for it, so no way to access it. I think most other plugins would never need to, but for NiFi we need to know if the reason for denying access was because no policy exists for the resource, or because a specific policy exists that doesn't match the incoming request.

So the best I could come up with was to intercept when the policies are refreshed and store the resource ids so that when RangerAccessResult getIsAllowed() returns false we can then do a second check to see if there was even a policy for the given resource, and if not then return resource not found, rather than denied.

[bbende]

@YolandaMDavis rebased against master to resolve conflicts and pushed a new commit that addresses your feedback

[YolandaMDavis]

@bbende all looks good on this end. Thanks Bryan!