Open Stack

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).

>  **
>
> ** **
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/e7a2fdbe/attachment.html>