Open Stack

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"... specifically when it comes to the sections about the trustor ID always being the user making the POST 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. 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