Open Stack

On Mon, Sep 16, 2013 at 6:18 PM, Lyle, David (Cloud Services) <
david.lyle at hp.com> wrote:

> "Adam Young" <ayoung at redhat.com> wrote:
>
> > Looks like this has grown into a full discussion.  Opening up to the dev
> mailing list.
>
> > On 09/16/2013 10:43 AM, Lyle, David (Cloud Services) wrote:
> >> I did run into a couple of fundamental limitations with the policy API
> as implemented in Keystone.
> >>
> >> 1)  policy_list and policy_get are admin_required by default in the
> policy file.  Obviously this can be changed in the policy file itself, but
> this is a bad default.  A regular user is most in need of policy rule
> enforcement so the existing default does not make sense from a UI
> perspective.
> >Hmmm, this sounds like a mismatch of expectations.  I would think that
> the Horizon server would fetch the policy as an admin user, not the end
> user, and use that to tailor their UX.  It would only be a problem if that
> tailoring was done on the Client side in Javascript.  Why would it matter
> what access control for the policy was?  Why would the end user be
> requesting the policy?
>
> Horizon does not have an admin authenticated user running in the
> background.  All privileges are based on the roles returned in the token
> from keystone when authenticating.  So allowing read access to the policy
> file for non-admin users allows the policy file to be accessed at all.
>

Given that keystone doesn't determine what privileges/capabilities a role
actually provides... Horizon shouldn't be expected to correctly interpret
every service's policy blob. A service is free to change it's policy
enforcement, and Horizon shouldn't have to duplicate that functionality.

In addition, every service shouldn't be expected to use centralized policy
storage.

>From my perspective, it only makes sense for Horizon to discover authorized
capabilities by making authenticated requests to each services (for
example, via OPTIONS).


>
> >>
> >> 2)  The 3 param/return fields supported by the policy API are: blob,
> id, type (mime-type).  When trying to utilize multiple policy files (blobs)
> from several services we need a way to map the blob to a service type to
> know which rule set to apply.  I had considered lumping all the policy
> blobs into one, but there is no requirement that each policy rule will
> begin with e.g., "identity:" and several blobs could implement a rule
> "default" which could be specified differently.  So, I believe a
> service_type parameter is necessary.  Additionally, is there anything
> barring nova from uploading multiple policy blobs (perhaps different), each
> getting unique IDs, and then having several varying compute policy blobs to
> choose from?  Which one wins?
> >I haven't looked deeply at the policy API until now:   It looks broken.
> >I would not be able to tell just from reading the code how to map a
> policy file to the service that needed it.  I would think that, upon
> service startup, it would request the policy file that mapped to it, either
> by endpoint with a fallback to a pre-service call.
>
> >I would think that you would make a tree out of the rules.  At the root
> would be policy.  Underneath that would be the service, (then the endpoint
> in the future when we support multiple per service) and then the rules
> underneath those.  The rules would be a json dumps of the blob get from the
> policy_api.
>
> A service type indicator allows would be the base addition again to
> differentiate ambiguous rules between blobs.  When the policy blob is
> uploaded the service type should be specified.  If that specifier is the
> service endpoint, that would work well and map extensibly.
>
> David
>
>
> >>
> >> Having devstack load the policy files into keystone would help, but 1
> and 2 need to be addressed before those files are usable in Horizon.
> >>
> >> Thanks,
> >> David
> >>
> >> -----Original Message-----
> >> From: Adam Young [mailto:ayoung at redhat.com]
> >> Sent: Monday, September 16, 2013 8:16 AM
> >> To: Julie Pichon
> >> Cc: Matthias Runge; Gabriel Hurley; Lyle, David (Cloud Services)
> >> Subject: Re: WebUI and user roles
> >>
> >>> On 09/16/2013 07:33 AM, Julie Pichon wrote:
> >>>> "Adam Young" <ayoung at redhat.com> wrote:
> >>>>> Gabriel and I talked at the last summit about how Horizon could
> >>>>> figure out what to show the user based on the roles that the user
> >>>>> had.  At the time, I was thinking it wasn't something we could
> figure out at run time.
> >>>>>
> >>>>> I was wrong.
> >>>>>
> >>>>> The answer is plain.  We have the policy files in Keystone already,
> >>>>> we just don't parse them.  Horizon has all the information it needs
> >>>>> to figure out "based on a token, what can this user do?"
> >>>>>
> >>>>> I'm not certain how to make use of this, yet, but the kernel of the
> >>>>> idea is there.
> >>>> Thanks Adam. David Lyle implemented RBAC functionality based on
> >>>> policy files in Havana [0]. I think one of the problems he found was
> >>>> that although policy files are in use, most services currently do not
> >>>> upload them to Keystone so they are not yet queryable (?).
> >>> That is true, but it is a deployment issue that is easily solvable. We
> can have devstack, packstack, and whatever else, upload the policy files at
> the start.  They are all in the various deployments, so it is really a
> trivial step to load them into Keystone.
> >>>
> >>>> Regards,
> >>>>
> >>>> Julie
> >>>>
> >>>>
> >>>> [0] https://blueprints.launchpad.net/horizon/+spec/rbac
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130916/5a4e6ff5/attachment.html>