Open Stack

Thank you guys!

Also, more than the add/delete/update services, the list services could operate based on the domain_id of the user that is calling it. Today there are the query strings to filter the search, but what happens if the user doesn´t use them? He will be able to list all projects from all domains, for example.


To deal with the domain_id and target.domain_id, what do you think if we take this information based on the user token_id? So, will not be necessary the user send the domain_id in the request.


Thanks,

Otavio

From: Henry Nash [mailto:henryn at linux.vnet.ibm.com]
Sent: quinta-feira, 6 de junho de 2013 12:06
To: OpenStack Development Mailing List
Cc: Knuppe, Gustavo (Brazil R&D-ECL); Gaspareto, Otavio; Rosa, Leandro (Brazil R&D-ECL)
Subject: Re: [openstack-dev] [keystone] Domain admin roles

To expand on Dolph's comments, the restriction in Grizzly  is that you can include a domain_id check in your policy file against apis - however, this will only work if the objects in the parameters of the api calls includes the domain_id (so that it can be checked by the policy engine).  So for instance you can restrict the creation of users, groups and projects to the domain scope of a user by including a policy rule like:

"domain_id:%(user.domain_id)s"
(substitute group or project for user in the above as required).

The issue is, of course, that this only works for create (since you are passing the object to create), but doesn't work for update or delete.  Extending keystone to enable rule definition that checks the object the api will operate on is what we are working on for Havana.

There is a blueprint for this already : https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target

Henry

On 6 Jun 2013, at 15:42, Dolph Mathews wrote:

We're on our way to supporting domain-based role assignments in policy.json, but it's not quite there in grizzly. Related bug:

  https://bugs.launchpad.net/keystone/+bug/1187198

(this should probably be turned into a blueprint)

-Dolph

On Thu, Jun 6, 2013 at 9:10 AM, Gaspareto, Otavio <otavio.barcelos-gaspareto at hp.com<mailto:otavio.barcelos-gaspareto at hp.com>> wrote:
Hi Dolph/Guang,

I'm implementing here a new role, called domain_admin, where the user with this role will be a manager inside his domain. For this, I've created this entry into the policy.json file:

"domain_admin_required" : [["role:domain_admin", "domain_id:%(domain_id)s"]],

Testing some services marked with this rule, and using an user that is a domain_admin I could perform operations in other domains, like create project.

So, my question: this rule "domain_id:%(domain_id)s" shouldn't block operations on domains different from mine?

Another info, I'm using domain scoped authentication.

Thanks,

Otavio Gaspareto
Software Designer


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/29b2d4f3/attachment.html>