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