I have noticed a discrepancy in the way policies are enforced between v2 and v3 
API calls. Namely, v3 calls pass the user and target contexts to the 
policy.enforce method, while v2's assert_admin only takes the user context into 
consideration. The differences appear here as far as I can tell:
 (v3) and here: 

I've experimented with roughly patching the v2 API to take the target context 
into account, but I have run into problems when manually testing it against the 
CLI. For example, calling 'keystone user-role-add' will list users, projects 
and roles to retrieve IDs prior to adding the role to a user, but these calls 
are admin only, and no target context is passed when doing these calls so they 
will fail if you want, for example, "tenant admins" in v2 (as in admin rights 
limited to actions related to a specific tenant). Therefore, such a patch would 
probably involve some work on the CLI as well.

I am aware the notion of "tenant admin" should probably be treated as business 
logic outside of keystone, but concerning the difference of treatment between 
policies enforcements:

* Was it a design decision ?
* If not, should the v2 API be patched so that the target context can be used 
with policies ? More generally speaking, what's the common opinion on this 
since the v2 API is deprecated from now on ?

Matthieu Huin 
11 bis rue roquépine – 75008 PARIS France

OpenStack-dev mailing list

Reply via email to