Set Up an Authorization Provider

The ACLAuthz provider determines who is able to access a service through the Knox Gateway by comparing the authenticated user, group, and originating IP address of the request to the rules defined in the authorization provider.

The Knox Gateway has an out-of-the-box authorization provider that allows administrators to restrict access to the individual services within a cluster. This provider utilizes a simple and familiar pattern of using ACLs to protect resources by specifying users, groups and ip addresses that are permitted access.

Group membership is determined by the identity-assertion parameter group.principal.mapping.

Open the cluster topology descriptor file, $cluster-name .xml, in a text editor.

Add a AclsAuthz authorization provider to topology/gateway with a parameter for each service as follows:

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>$service_name.acl.mode</name>
        <value>$mode</value>
    </param>
    <param>
        <name>$service_Name.acl</name>
        <value>$cluster_users;$groups_field;IP_field</value>
    </param>
    ...
</provider>

where:

$service_name matches the name of a service element. For example,webhdfs.
$mode determines how the identity context (the effective user, their associated groups, and the original IP address) is evaluated against the fields as follows:
- AND specifies that the request must match an entry in all three fields of the corresponding $service_name .acl parameter.
- OR specifies that the request only needs to match an entry in any field, $users_field OR $groups_field, OR $IP_field.
$cluster_users is a comma-separated list of authenticated users. Use a wildcard (*) to match all users.
$groups_field is a comma-separated list of groups. Use a wildcard (*) to match all groups.
$IP_field is a comma-separated list of IPv4 or IPv6 addresses. An IP address in the list can contain wildcard at the end to indicate a subnet (for example: 192.168.*). Use a wildcard (*) to match all addresses.

	Note
	The `$service_name .acl.mode` parameter is optional. When it is not defined, the default mode is `AND` ; therefore requests to that service must match all three fields.

Save the file.
The gateway creates a new WAR file with modified timestamp in $gateway/data/deployments.

Only users in a specific group and from specific IP addresses

The following rule is restrictive. It only allows the guest user in the admin group to access WebHDFS from a system with the IP address of either 127.0.0.2 or 127.0.0.3:

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>webhdfs.acl</name>
        <value>guest;admin;127.0.0.2,127.0.0.3</value>
    </param>
</provider>

When the parameter acl.mode is not defined the default behavior is ALL, therefore following rule is the same as the one above:

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>webhdfs.acl.mode</name>
        <value>AND</value>
    </param>
    <param>
        <name>webhdfs.acl</name>
        <value>guest;admin;127.0.0.2,127.0.0.3</value>
    </param>
</provider>

	Note
	If Guest is not in the admin group, the request is denied.

Two of the three conditions

The following rule demonstrates how to require two conditions, user and group but not IP address, using the Wildcard. The rule allows the guest user that belongs to the admin group to send requests from anywhere because the IP field contains an asterisk which matches all IP addresses:

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>webhdfs.acl</name>
        <value>guest;admin;*</value>
    </param>
</provider>

One of the three conditions

When the $service .acl.mode parameter is set to OR, the request only needs to match one entry in any of the fields. The request fails with HTTP Status 403 unauthorized, if no conditions are met.

The following example allows:

guest to send requests to WebHDFS from anywhere.
Any user in the admin group to send requests to WebHDFS from anywhere.

Any user, in any group, to send a request to WebHDFS from 127.0.0.2 or 127.0.0.3.

<provider>
    <role>authorization</role>
    <name>AclsAuthz</name>
    <enabled>true</enabled>
    <param>
        <name>webhdfs.acl.mode</name>
        <value>OR</value>
    </param>
    <param>
        <name>webhdfs.acl</name>
        <value>guest;admin;127.0.0.2,127.0.03</value>
    </param>
</provider>

Allow all requests

The following rule grants all users, in any group, and from any IP addresses to access WebHDFS:

	Note
	When a wildcard is used in a field it matches any value. Therefore the Allow all requests example is the same as not defining an ACL. `<provider> <role>authorization</role> <name>AclsAuthz</name> <enabled>true</enabled> <param> <name>webhdfs.acl</name> <value>,,*</value> </param> </provider>`