Open Stack

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 <lbragstad at gmail.com> wrote:

>
>
> On Fri, May 26, 2017 at 10:21 AM, Sean Dague <sean at 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-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170531/d4817da0/attachment.html>