
<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    Sean had a really good point when he mentioned that the Developers

    know what need to be enforced, and I think this is why he suggested

    that the base policy implementation be in Python code, not the

    policy JSON DSL.<br>

    <br>

    The main thrust of the dynamic policy has been to get the

    role-to-api assignment more flexible.  However, there is another

    side to each policy rule; figureing out where the project (nee'

    tenant) id is in the request;  is it part of the URL, part of the

    request body, or in the object returned from the database.  This

    part really should be handled by the developer working on the policy

    rule, and it should not be changed.<br>

    <br>

    So...what if we say that we split policy into two checks;  a role

    check, and a scope check.  Both checks must pass in order for the

    user to get access to the API.  The Scope check is not going to be

    dynamic;  once set, they will pretty much stay set.   It might be

    done using the policy.json, or done in code, but it will be separate

    from the role check.<br>

    <br>

    <br>

    <p>The Neutron policy checks for things like </p>

    <p><code> "shared": "field:networks:shared=True",

        "shared_firewalls": "field:firewalls:shared=True",

        "shared_firewall_policies":

        "field:firewall_policies:shared=True", "shared_subnetpools":

        "field:subnetpools:shared=True",<br>

        <br>

        Would be handled by the dev teams later policy check; anything

        that requires actually fetching the object from the database is

        postponed to this stage.<br>

      </code></p>

    <br>

    <br>

    The role check will come from the policy.json file.  This will allow

    the operator to fine tune how roles are handled.  Any thing else

    that can be explicitly checked based on the token will be fair game,

    but not API specific values;  no database fetch will be performed at

    this point.  The assumption is that this policy check could be

    generic enough to be performed in middleware, and might even be

    enforced based on the URL instead of the pseudo random namespacing

    we do now.<br>

    <br>

    Does this suggestion work for Nova?  I think it will make the

    overall policy much easier to maintain in the field.<br>

  </body>

</html>