On Mon, Sep 16, 2013 at 6:18 PM, Lyle, David (Cloud Services) < [email protected]> wrote:
> "Adam Young" <[email protected]> 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:[email protected]] > >> 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" <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
