I took a stab at working through the API a bit more and I've capture that information in the spec [0]. Rendered version is available, too [1].
[0] https://review.openstack.org/#/c/464763/ [1] http://docs-draft.openstack.org/63/464763/12/check/gate-keystone-specs-docs-ubuntu-xenial/1dbeb65//doc/build/html/specs/keystone/ongoing/global-roles.html On Wed, May 31, 2017 at 9:10 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > > > On Fri, May 26, 2017 at 10:21 AM, Sean Dague <s...@dague.net> wrote: > >> On 05/26/2017 10:44 AM, Lance Bragstad wrote: >> <snip> >> > Interesting - I guess the way I was thinking about it was on a per-token >> > basis, since today you can't have a single token represent multiple >> > scopes. Would it be unreasonable to have oslo.context build this >> > information based on multiple tokens from the same user, or is that a >> > bad idea? >> >> No service consumer is interacting with Tokens. That's all been >> abstracted away. The code in the consumers consumer is interested in is >> the context representation. >> >> Which is good, because then the important parts are figuring out the >> right context interface to consume. And the right Keystone front end to >> be explicit about what was intended by the operator "make jane an admin >> on compute in region 1". >> >> And the middle can be whatever works best on the Keystone side. As long >> as the details of that aren't leaked out, it can also be refactored in >> the future by having keystonemiddleware+oslo.context translate to the >> known interface. >> > > Ok - I think that makes sense. So if I copy/paste your example from > earlier and modify it a bit ( s/is_admin/global/):: > > { > "user": "me!", > "global": True, > "roles": ["admin", "auditor"], > .... > } > > Or > > { > "user": "me!", > "global": True, > "roles": ["reader"], > .... > } > > That might be one way we can represent global roles through > oslo.context/keystonemiddleware. > The library would be on the hook for maintaining the mapping of token scope > to context scope, which makes sense: > > if token['is_global'] == True: > context.global = True > elif token['domain_scoped']: > # domain scoping? > else: > # handle project scoping > > I need to go dig into oslo.context a bit more to get familiar with how > this works on the project level. Because if I understand correctly, > oslo.context currently doesn't relay global scope and that will be a > required thing to get done before this work is useful, regardless of going > with option #1, #2, and especially #3. > > > >> -Sean >> >> -- >> Sean Dague >> http://dague.net >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
