My understanding from the summit session was that we should have a specific role defined in keystone's policy.json here: https://github.com/openstack/keystone/blob/a16287af5b7761c8453b2a8e278d78652497377c/etc/policy.json#L37 Which grants access to nothing in keystone beyond that check. So, the new rule could be revised to something as generic as: "identity:get_project": "rule:admin_required or project_id:%( target.project.id)s or role:identity_get_project", Where the new role name I appended at the end exactly matches the policy rule name. However, unlike the summit discussion, which specified only providing access to HEAD /v3/projects/{project_id}, keystone's usage of policy unfortunately wraps both HEAD and GET with the same policy check. On Thu, May 5, 2016 at 3:05 PM Augustina Ragwitz <aragwitz.lists at pobox.com> wrote: > I'm currently working on the spec for Project ID Validation in Nova > using Keystone. The outcome of the Design Summit Session was that the > Nova service user would use the Keystone policy to establish whether the > requester had access to the project at all to verify the id. I was > wondering if there were any code examples of a non-Keystone service > using the Keystone policy in this way? > > Also if I misunderstood something, please feel free to correct me or to > clarify! > > Here is the etherpad from the session: > https://etherpad.openstack.org/p/newton-nova-keystone > And here is the current spec: https://review.openstack.org/#/c/294337 > > > -- > Augustina Ragwitz > Sr Systems Software Engineer, HPE Cloud > Hewlett Packard Enterprise > --- > irc: auggy > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160505/49d32a6d/attachment.html>