Open Stack

On Mon, Sep 16, 2013 at 11:01 AM, 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?
>
>
>> 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: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<https://blueprints.launchpad.net/horizon/+spec/rbac>
>>>
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/038aff1c/attachment.html>