<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    There are a few Keystone features that are coming together for
    Kilo.  Endpoint binding of tokens is one, and I think can be handled
    completely in keystonemiddelware.auth_token.  Another, though, is
    based on a few requests we've had to be able to have policy
    performed against a specific object or API based on what is in the
    token.<br>
    <br>
    The token would have a new section 'constraints', parallel to
    'scope'.  It will contain one or more of the following.<br>
    <br>
      `endpoints` : a list with each of the endpoint ids explcitly
    enumerated.<br>
      `operations` : a list of the APIs as definied in the policy rules
    file.<br>
      `entities`:  a list of the object identifiers.<br>
    <br>
    If any section is not explicitly set, there are no constraints of
    that kind.<br>
    <br>
    For example, if all three were specified, the token would contain
    something like:<br>
    <br>
    <br>
    constraints: {<br>
        endpoints: ['novaepid', 'glanceepid'],<br>
        operations: ["<span class="nt">compute:create"</span><span
      class="p">,</span><span class="p"> <span class="nt">"compute:start"</span><span
        class="p">, </span></span><span class="nt">"network:associate"</span><span
      class="p">,</span><span class="nt">"network:get_floating_ip",    <br>
                              "image:get_image","network:update_port" </span><span
      class="p">],<br>
          entities:['imageid1','networkport2']<br>
      }<br>
      <br>
      Since the nova server would not have created the instance yet,
      there would be no restriction on the create call.  Only the
      specified image with id </span><span class="p"><span class="p">'imageid1'</span>
      would be accessible from glance, and only the "get_image" API
      would be allowed on glance.  Only access to </span><span
      class="p">'networkport2' would be granted from Neutron.<br>
    </span><span class="p"><br>
      <br>
      To enforce the 'operations' constraint, we can modify the policy
      enforcer  here:<br>
      <br>
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/policy.py#n290">http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/policy.py#n290</a><br>
      <br>
      A check like:<br>
      <br>
      if creds.token.get('constraints',{}).get('operations') and rule
      not in </span><span class="p"><span class="p">creds.token.constraint.operations</span>:<br>
             raise PolicyNotAuthorized(rule)<br>
      <br>
      <br>
      I'm not, however, certain how to standardize the "entities"
      portion of it.  Any suggestions?<br>
      <br>
      <br>
      For endpoint binding, an endpoint will have to know its own id.  
      So the endpoint_id will be recorded in the config file.  This
      means that the endpoint should be created in keystone before
      bringing up the server.  Since we already require workflow like
      this to create the service users, this should not be too big a
      burden.  Then that becomes a check here:<br>
      <br>
<a class="moz-txt-link-freetext" href="http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n863">http://git.openstack.org/cgit/openstack/keystonemiddleware/tree/keystonemiddleware/auth_token.py#n863</a><br>
      <br>
      which looks like :<br>
      <br>
    </span>if<code> data<span class="hl opt">[</span><span class="hl
        str">'access'</span><span class="hl opt">][</span><span
        class="hl str">'token'</span><span class="hl opt">].get(</span><span
        class="hl str">'constrains'</span><span class="hl opt">,{}).get('endpoints')
        and CONF.endpoint_id not in </span></code><br>
    <span class="p"><code>data<span class="hl opt">[</span><span
          class="hl str">'access'</span><span class="hl opt">][</span><span
          class="hl str">'token'</span><span class="hl opt">][</span><span
          class="hl str">'constrains'</span><span class="hl opt">]['endpoints']</span></code>:<br>
         </span><code><span class="hl kwa">raise</span> <span
        class="hl kwd">InvalidToken</span><span class="hl opt">(</span><span
        class="hl str">'Endpoint constraint not met'</span><span
        class="hl opt">)</span></code><span class="p"><br>
      <br>
      The WIP spec is here: <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/123726/">https://review.openstack.org/#/c/123726/</a>  <br>
      <br>
      please provide feedback on content.  I'll deal with formatting
      once it is roughed out.<br>
      <br>
      <br>
    </span>
  </body>
</html>