Open Stack

On 6 Jun 2013, at 21:44, Dolph Mathews wrote:

> On Thu, Jun 6, 2013 at 1:19 PM, Gaspareto, Otavio <otavio.barcelos-gaspareto at hp.com> wrote:
> 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.
> 
> Services don't have any mapping to domains, so I'm not sure I understand the desired behavior here.
> 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.
> 
> 
> Yes, that's by design (you're literally querying for the entire collection, so that's what you should receive, if not a 403). If policy.json was written to require domain-specific authorization, I would expect this to either require the user to specify the domain in a query string, the results to be limited to projects from the token's scope, or both. I vastly prefer both because I don't like two requests to return different results where it's not obvious as to why they are different (even with Vary: X-Auth-Token).

...and indeed that is what is in Grizzly.  If you protect the list api with requiring a domain_id, then if you try and list everything you will get "Not Authorised", and the call will only succeed if you specify your domain_id in the query string (in which case only the items for your domain will be returned).
>  
> 
>  
> 
> 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.
> 
> The target's domain_id should have to match the domain of a domain-scoped token (which is not necessarily the user's domain ID).
> 
>  
> 
>  
> 
> 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> 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
> 
> 
>  
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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