<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">One thing we could do is:<div><br></div><div>- Return Forbidden or NotFound if we can determine the correct answer</div><div>- When we can't (i.e. the object doesn't exist), then return NotFound unless a new config value 'policy_harden' (?) is set to true (default false) in which case we translate NotFound into Forbidden.</div><div><br></div><div>Henry<br><div><div>On 23 Jul 2013, at 18:31, Adam Young wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/23/2013 12:54 PM, David Chadwick
      wrote:<br>
    </div>
    <blockquote cite="mid:51EEB53A.1070909@kent.ac.uk" type="cite">When
      writing a previous ISO standard the approach we took was as
      follows
      <br>
      <br>
      Lie to people who are not authorised.
      <br>
    </blockquote>
    <br>
    Is that your verbage?  I am going to reuse that quote, and I would
    like to get the attribution correct.<br>
    <br>
    <blockquote cite="mid:51EEB53A.1070909@kent.ac.uk" type="cite">
      <br>
      So applying this approach to your situation, you could reply Not
      Found to people who are authorised to see the object if it had
      existed but does not, and Not Found to those not authorised to see
      it, regardless of whether it exists or not. In this case, only
      those who are authorised to see the object will get it if it
      exists. Those not authorised cannot tell the difference between
      objects that dont exist and those that do exist
      <br>
    </blockquote>
    <br>
    So, to try and apply this to a semi-real example:  There are two
    types of URLs.  Ones that are like this:<br>
    <br>
    users/55FEEDBABECAFE<br>
    <br>
    and ones like this:<br>
    <br>
    domain/66DEADBEEF0000/users/55FEEDBABECAFE<br>
    <br>
    <br>
    In the first case, you are selecting against a global collection,
    and in the second, against a scoped collection.<br>
    <br>
    For unscoped, you have to treat all users as equal, and thus a 404
    probably makes sense.<br>
    <br>
    For a scoped collection we could return a 404 or a <a href="https://en.wikipedia.org/wiki/HTTP_403" title="HTTP 403">403
      Forbidden</a> based on the users credentials:  all resources under
    domain/66DEADBEEF0000  would show up as 403s regardless of
    existantce or not if the user had no roles in the domain
    66DEADBEEF0000.  A user that would be allowed access to resources in
    66DEADBEEF0000  would get a 403 only for an object that existed but
    that they had no permission to read, and 404 for a resource that
    doesn't exist.<br>
    <br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:51EEB53A.1070909@kent.ac.uk" type="cite">
      <br>
      regards
      <br>
      <br>
      David
      <br>
      <br>
      <br>
      On 23/07/2013 16:40, Henry Nash wrote:
      <br>
      <blockquote type="cite">Hi
        <br>
        <br>
        As part of bp
        <a class="moz-txt-link-freetext" href="https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target">https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target</a>
        I have uploaded some example WIP code showing a proposed
        approach for just a few API calls (one easy, one more complex). 
        I'd appreciate early feedback on this before I take it any
        further.
        <br>
        <br>
        <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/38308/">https://review.openstack.org/#/c/38308/</a>
        <br>
        <br>
        A couple of points:
        <br>
        <br>
        - One question is on how to handle errors when you are going to
        get a target object before doing you policy check.  What do you
        do if the object does not exist?  If you return NotFound, then
        someone, who was not authorized  could troll for the existence
        of entities by seeing whether they got NotFound or Forbidden. 
        If however, you return Forbidden, then users who are authorized
        to, say, manage users in a domain would aways get Forbidden for
        objects that didn't exist (since we can know where the
        non-existant object was!).  So this would modify the expected
        return codes.
        <br>
        <br>
        - I really think we need some good documentation on how to bud
        keystone policy files.  I'm happy to take a first cut as such a
        thing - what do you think the right place is for such
        documentation
        <br>
        <br>
        _______________________________________________
        <br>
        OpenStack-dev mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
        <br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
        <br>
        <br>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      OpenStack-dev mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
      <br>
    </blockquote>
    <br>
  </div>

_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></div></body></html>