Authorization Policy Enforcement¶

Request authorization¶

The aim of this step is to authorize processing for a request or reject it with an error status code. This step uses the neutron.policy.enforce routine. This routine raises oslo_policy.PolicyNotAuthorized when policy enforcement fails. The Neutron REST API controllers catch this exception and return:

• A 403 response code on a POST request or an PUT request for an object owned by the project submitting the request;
• A 403 response for failures while authorizing API actions such as add_router_interface;
• A 404 response for DELETE, GET and all other PUT requests.

For DELETE operations the resource must first be fetched. This is done invoking the same _item [3] method used for processing GET requests. This is also true for PUT operations, since the Neutron API implements PATCH semantics for PUTs. The criteria to evaluate are built in the _build_match_rule [4] routine. This routine takes in input the following parameters:

• The action to be performed, in the <operation>_<resource> form, e.g.: create_network
• The data to use for performing checks. For POST operations this could be a partial specification of the object, whereas it is always a full specification for GET, PUT, and DELETE requests, as resource data are retrieved before dispatching the call to the plugin layer.
• The collection name for the resource specified in the previous parameter; for instance, for a network it would be the “networks”.

The _build_match_rule routine returns a oslo_policy.RuleCheck instance built in the following way:

• Always add a check for the action being performed. This will match a policy like create_network in policy.json;
• Return for GET operations; more detailed checks will be performed anyway when building the response;
• For each attribute which has been explicitly specified in the request create a rule matching policy names in the form <operation>_<resource>:<attribute> rule, and link it with the previous rule with an ‘And’ relationship (using oslo_policy.AndCheck); this step will be performed only if the enforce_policy flag is set to True in the resource attribute descriptor (usually found in a data structure called RESOURCE_ATTRIBUTE_MAP);
• If the attribute is a composite one then further rules will be created; These will match policy names in the form <operation>_<resource>: <attribute>:<sub_attribute>. An ‘And’ relationship will be used in this case too.

As all the rules to verify are linked by ‘And’ relationships, all the policy checks should succeed in order for a request to be authorized. Rule verification is performed by oslo_policy with no “customization” from the Neutron side.

Response Filtering¶

Some Neutron extensions, like the provider networks one, add some attribute to resources which are however not meant to be consumed by all clients. This might be because these attributes contain implementation details, or are meant only to be used when exchanging information between services, such as Nova and Neutron;

For this reason the policy engine is invoked again when building API responses. This is achieved by the _exclude_attributes_by_policy [5] method in neutron.api.v2.base.Controller;

This method, for each attribute in the response returned by the plugin layer, first checks if the is_visible flag is True. In that case it proceeds to checking policies for the attribute; if the policy check fails the attribute is added to a list of attributes that should be removed from the response before returning it to the API client.

OwnerCheck: Extended Checks for Resource Ownership¶

This class is registered for rules matching the tenant_id keyword and overrides the generic check performed by oslo_policy in this case. It uses for those cases where neutron needs to check whether the project submitting a request for a new resource owns the parent resource of the one being created. Current usages of OwnerCheck include, for instance, creating and updating a subnet.

The check, performed in the __call__ method, works as follows:

• verify if the target field is already in the target data. If yes, then simply verify whether the value for the target field in target data is equal to value for the same field in credentials, just like oslo_policy.GeneriCheck would do. This is also the most frequent case as the target field is usually tenant_id;
• if the previous check failed, extract a parent resource type and a parent field name from the target field. For instance networks:tenant_id identifies the tenant_id attribute of the network resource;
• if no parent resource or target field could be identified raise a PolicyCheckError exception;
• Retrieve a ‘parent foreign key’ from the RESOURCE_FOREIGN_KEYS data structure in neutron.api.v2.attributes. This foreign key is simply the attribute acting as a primary key in the parent resource. A PolicyCheckError exception will be raised if such ‘parent foreign key’ cannot be retrieved;
• Using the core plugin, retrieve an instance of the resource having ‘parent foreign key’ as an identifier;
• Finally, verify whether the target field in this resource matches the one in the initial request data. For instance, for a port create request, verify whether the tenant_id of the port data structure matches the tenant_id of the network where this port is being created.

FieldCheck: Verify Resource Attributes¶

This class is registered with the policy engine for rules matching the ‘field’ keyword, and provides a way to perform fine grained checks on resource attributes. For instance, using this class of rules it is possible to specify a rule for granting every project read access to shared resources.

In policy.json, a FieldCheck rules is specified in the following way:

> field: <resource>:<field>=<value>

This will result in the initialization of a FieldCheck that will check for <field> in the target resource data, and return True if it is equal to <value> or return False is the <field> either is not equal to <value> or does not exist at all.