Open Stack

On 2/22/19 12:22 PM, Colleen Murphy wrote:
> On Fri, Feb 22, 2019, at 5:27 PM, Lance Bragstad wrote:
>>
>> On 2/22/19 4:54 AM, Colleen Murphy wrote:
>>> On Thu, Feb 21, 2019, at 11:32 PM, Lance Bragstad wrote:
>>>> On 2/21/19 3:11 PM, Colleen Murphy wrote:
>>> [snipped]
>>>
>>>>> * Substitutions
>>>>>
>>>>> The way the spec lays out variable components of the URL paths for both
>>>>> user-created-rules and operator-created-rules is unnecessarily complex and in
>>>>> some cases faulty. The only way I can explain how complicated it is is to try 
>>>>> to give an example:
>>>>>
>>>>> Let's say we want to allow a user to create an application credential that
>>>>> allows the holder to issue a GET request on the identity API that looks like
>>>>> /v3/projects/ef7284b4-3a75-4570-8ea8-b30214f18538/tags/foobar. The spec says
>>>>> that the string '/v3/projects/{project_id}/tags/{tag}' is what should be
>>>>> provided verbatim in the "path" attribute of a "capability", then there should
>>>>> be a "substitutions" attribute that sets {"tag": "foobar"}, then the project_id
>>>>> should be taken from the token scope at app cred usage time. When the 
>>>>> capability is validated against the operator-created-rules at app cred creation
>>>>> time, it needs to check that the path string matches exactly, that the keys of
>>>>> the "substitutions" dict matches the "user template keys" list, and that keys
>>>>> required by the "context template keys" are provided by the token context.
>>>>>
>>>>> Taking the project ID, domain ID, or user ID from the token scope is not going
>>>>> to work because some of these APIs may actually be system-scoped APIs - it's
>>>>> just not a hard and fast rule that a project/domain/user ID in the URL maps to
>>>>> the same user and scope of the token used to create it. Once we do away with
>>>>> that, it stops making sense to have a separate attribute for the user-provided
>>>>> substitutions when they could just include that in the URL path to begin with.
>>>>> So the proposed implementation simply allows the wildcards * and ** in both the 
>>>>> operator-created-rules and user-created-rules, no python-formatting variable
>>>>> substitutions.
>>>> I agree about the awkwardness and complexity, but I do want to clarify.
>>>> Using the example above, going with * and ** would mean that tokens
>>>> generated from that application credential would be actionable on any
>>>> project tag for the project the application credential was created for
>>>> and not just 'foobar'.
>>> Not exactly. Say the operator has configured a rule like:
>>>
>>> GET /v3/projects/*/tags/*
>>>
>>> The user then has the ability to configure one or more of several rules:
>>>
>>> GET /v3/projects/*/tags/* # this application credential can be used on any project on any tag
>>> GET /v3/projects/UUID/tags/* # this application credential can be used on a specific project on any tag
>>> GET /v3/projects/*/tags/foobar # this application credential can be used on any project but only for tag "foobar"
>>> GET /v3/projects/UUID/tags/foobar # this application credential can only be used on one specific project and one specific tag
>>>
>>> The matching rule for capability creation would be flexible enough to allow any of these.
>> Oh - so we're just not allowing for the substitution to be a formal
>> attribute of the application credential?
> Right, and similarly the list of "user template keys" and "context template keys" in the operator-created-rules won't be needed any more.

Awesome, I'm on board. This is more usable than how I originally
interpreted the email. We can always revisit this later, too.

>
>>>> For an initial implementation, I think that's fine. Sure, creating an
>>>> application credential specific to a single server is ideal, but at
>>>> least we're heading in the right direction by limiting its usage to a
>>>> single API. If we get that right - we should be able to iteratively add
>>>> filtering later*. I wouldn't mind re-raising this particular point after
>>>> we have more feedback from the user community.
>>>>
>>>> * iff we need to
>>>>
>>> [snipped]
>>>
>>> Colleen
>>>
>>
>>
>> Attachments:
>> * signature.asc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190222/f3692c33/attachment.sig>