Open Stack

Hi Gabriel

you make some good points

On 03/12/2012 22:41, Gabriel Hurley wrote:
> Good to know re: the ports. Still curious if there's any thought to
> capabilities that might be allowed via expanded RBAC permissions for
> an "administrative user"...

This should certainly be allowed, and could be via an admin port rather 
than a user port.

  specifically when it comes to the
> sections about the trustor ID always being the user making the POST

this also needs refining when recursive delegation is implemented, since 
the original trustee becomes the trustor in the second delegation.

> and that "Only the trustor or trustee will be able to access this
> URL. Any other user will get a 403 (Forbidden)." A few possible
> things an administrator might think to do are to "clean up" trusts if
> they get out-of-whack somehow, or to try and audit/understand the
> trusts in the system.

there needs to be a housekeeping routine which regulary disposes of 
expired (and unrevoked) trusts. This might run periodically or also be 
kicked off by an administrator.

David

  Maybe these aren't the kinds of use cases we
> want to allow, but if not I think we need to be more explicit about
> it and offer reasons why not.
>
> - Gabriel
>
>> -----Original Message----- From: heckj [mailto:heckj at mac.com] Sent:
>> Monday, December 03, 2012 1:26 PM To: OpenStack Development Mailing
>> List Subject: Re: [openstack-dev] [Keystone] Trust Specification
>> Updated
>>
>> Trusts are getting built on the V3 API, which will run equally on
>> both ports using RBAC as it's means to control access, as opposed
>> to the V2 mechanism that required the separate ports for
>> administrative vs. expected-user-access controls.
>>
>> We'll be keeping both ports active in the codebase until we've
>> fully deprecated the V2 APIs, but with the V3 APIs, only a single
>> port will be needed (pretty much like all the other OpenStack
>> projects)
>>
>> -joe
>>
>> On Dec 3, 2012, at 12:40 PM, Gabriel Hurley
>> <gabriel.hurley at nebula.com> wrote:
>>> Generally looks really good... one question though, sparked by
>>> the
>> sentence "The trustor ID is implied from the creating users ID."
>> Nowhere in that document does it describe the breakdown between the
>> standard interface (port 5000) vs. the administrative interface
>> (port 35357). What capabilities (or lack thereof) does a user with
>> administrative access have in this system, and can we make that
>> more explicit?
>>>
>>> Thanks,
>>>
>>> - Gabriel
>>>
>>>> -----Original Message----- From: Adam Young
>>>> [mailto:ayoung at redhat.com] Sent: Monday, December 03, 2012 8:35
>>>> AM To: OpenStack Development Mailing List Subject:
>>>> [openstack-dev] [Keystone] Trust Specification Updated
>>>>
>>>> I realize we have had a little bit of disagreement on what to
>>>> call this.  I am going to continue to call it "Trusts" as it is
>>>> a subset of the set of mechanisms for delegation.
>>>>
>>>> I've wikified the Specification.  Big thanks to David Chatwick
>>>> for making this a much better spec.
>>>>
>>>> http://wiki.openstack.org/Keystone/Trusts
>>>>
>>>> Blueprint is still at
>>>>
>>>> https://blueprints.launchpad.net/keystone/+spec/trusts
>>>>
>>>>
>>>> I will continue to work on this, to include, for example, how
>>>> to specifiy duration and start times, but there should be
>>>> enough here for people to understand.
>>>>
>>>> My initial write up:
>>>>
>>>> http://adam.younglogic.com/2012/10/preauthorization-in-keystone/
>>>>
>>>>
>>>>
_______________________________________________
>>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>>>
_______________________________________________
>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>>
_______________________________________________
>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>