On Mon, Sep 16, 2013 at 11:01 AM, 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? > > >> 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. > We stopped short of any policy -> service/endpoint mapping because there were mixed expectations about how that should be done and no clear use case that fetching policies by ID / URL didn't satisfy a bit more simply. > > 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. > > > > >> 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<https://blueprints.launchpad.net/horizon/+spec/rbac> >>> >> > > ______________________________**_________________ > OpenStack-dev mailing list > [email protected].**org <[email protected]> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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
