Authentication and authorization

Networking uses the Identity Service as the default authentication service. When the Identity Service is enabled, users who submit requests to the Networking service must provide an authentication token in X-Auth-Token request header. Users obtain this token by authenticating with the Identity Service endpoint. For more information about authentication with the Identity Service, see OpenStack Identity Service API v2.0 Reference. When the Identity Service is enabled, it is not mandatory to specify the tenant ID for resources in create requests because the tenant ID is derived from the authentication token.

	Note
	The default authorization settings only allow administrative users to create resources on behalf of a different tenant. Networking uses information received from Identity to authorize user requests. Networking handles two kind of authorization policies:

The policy engine reads entries from the policy.json file. The actual location of this file might vary from distribution to distribution. Entries can be updated while the system is running, and no service restart is required. Every time the policy file is updated, the policies are automatically reloaded. Currently the only way of updating such policies is to edit the policy file. In this section, the terms policy and rule refer to objects that are specified in the same way in the policy file. There are no syntax differences between a rule and a policy. A policy is something that is matched directly from the Networking policy engine. A rule is an element in a policy, which is evaluated. For instance in create_subnet: [["admin_or_network_owner"]], create_subnet is a policy, and admin_or_network_owner is a rule.

Policies are triggered by the Networking policy engine whenever one of them matches an Networking API operation or a specific attribute being used in a given operation. For instance the create_subnet policy is triggered every time a POST /v2.0/subnets request is sent to the Networking server; on the other hand create_network:shared is triggered every time the shared attribute is explicitly specified (and set to a value different from its default) in a POST /v2.0/networks request. It is also worth mentioning that policies can be also related to specific API extensions; for instance extension:provider_network:set is be triggered if the attributes defined by the Provider Network extensions are specified in an API request.

An authorization policy can be composed by one or more rules. If more rules are specified, evaluation policy succeeds if any of the rules evaluates successfully; if an API operation matches multiple policies, then all the policies must evaluate successfully. Also, authorization rules are recursive. Once a rule is matched, the rule(s) can be resolved to another rule, until a terminal rule is reached.

The Networking policy engine currently defines the following kinds of terminal rules:

This extract is from the default policy.json file:

{
   "admin_or_owner":[ 
      [
         "role:admin"
      ],
      [
         "tenant_id:%(tenant_id)s"
      ]
   ],
   "admin_or_network_owner":[
      [
         "role:admin"
      ],
      [
         "tenant_id:%(network_tenant_id)s"
      ]
   ],
   "admin_only":[
      [
         "role:admin"
      ]
   ],
   "regular_user":[

   ],
   "shared":[
      [
         "field:networks:shared=True"
      ]
   ],
   "default":[ 
      [
         "rule:admin_or_owner"
      ]
   ],
   "create_subnet":[
      [
         "rule:admin_or_network_owner"
      ]
   ],
   "get_subnet":[
      [
         "rule:admin_or_owner"
      ],
      [
         "rule:shared"
      ]
   ],
   "update_subnet":[
      [
         "rule:admin_or_network_owner"
      ]
   ],
   "delete_subnet":[
      [
         "rule:admin_or_network_owner"
      ]
   ],
   "create_network":[

   ],
   "get_network":[ 
      [
         "rule:admin_or_owner"
      ],
      [
         "rule:shared"
      ]
   ],
   "create_network:shared":[ 
      [
         "rule:admin_only"
      ]
   ],
   "update_network":[
      [
         "rule:admin_or_owner"
      ]
   ],
   "delete_network":[
      [
         "rule:admin_or_owner"
      ]
   ],
   "create_port":[

   ],
   "create_port:mac_address":[ 
      [
         "rule:admin_or_network_owner"
      ]
   ],
   "create_port:fixed_ips":[
      [
         "rule:admin_or_network_owner"
      ]
   ],
   "get_port":[
      [
         "rule:admin_or_owner"
      ]
   ],
   "update_port":[
      [
         "rule:admin_or_owner"
      ]
   ],
   "delete_port":[
      [
         "rule:admin_or_owner"
      ]
   ]
}

In some cases, some operations are restricted to administrators only. This example shows you how to modify a policy file to permit tenants to define networks and see their resources and permit administrative users to perform all other operations:

{
        "admin_or_owner": [["role:admin"], ["tenant_id:%(tenant_id)s"]],
        "admin_only": [["role:admin"]], "regular_user": [],
        "default": [["rule:admin_only"]],
        "create_subnet": [["rule:admin_only"]],
        "get_subnet": [["rule:admin_or_owner"]],
        "update_subnet": [["rule:admin_only"]],
        "delete_subnet": [["rule:admin_only"]],
        "create_network": [],
        "get_network": [["rule:admin_or_owner"]],
        "create_network:shared": [["rule:admin_only"]],
        "update_network": [["rule:admin_or_owner"]],
        "delete_network": [["rule:admin_or_owner"]],
        "create_port": [["rule:admin_only"]],
        "get_port": [["rule:admin_or_owner"]],
        "update_port": [["rule:admin_only"]],
        "delete_port": [["rule:admin_only"]]
        }