Retrieve Authentication Scoped Data¶
We need routes that allow us to retrieve information relevant to the current authentication scope.
Determining data associated with the current authorization scope requires extracting information from the token and then constructing URLs based on that information. This is a problem with calls for which the information is based on multiple factors. It is also a problem for the client where we are actively trying to encapsulate the authentication information so that you don’t have to know the parameters of your current authentication.
There has recently been a change to expose the service catalog based on the
current authentication token. However this is not the only thing that needs to
be determined on a per token basis. For example federated tokens need a
separate URL to determine the projects as there is no determinable
that can be put into the standard URL.
I propose we repurpose the rest of the
/auth URL to provide resources based
on the current authentication scope. This has a number of immediate URL
GET /v3/auth/projects. This lists the projects that a new scoped token can be requested for using the current token as authentication. This route can be used as a replacement for both the federation and regular user based project lookup. It will allow for projects to be associated with the current authentication via more that just user association. Deprecate
GET /v3/OS-FEDERATION/projectsin favour of this.
GET /v3/auth/domains. List the domains that a new scoped token can be requested for using the current token as authentication. As with projects this combines the federated and regular domain lookup cases. Deprecate
GET /v3/OS-FEDERATION/domainsin favour of this.
I feel this also simplifies the security model because it means all requests to
/auth are purely based on the current authentication scope rather than
dealing with matching filter arguments to the current scope.
It also opens up future options for matching available projects and domains
based on more than the
Currently I am not proposing to add
POST or modifying routes to the URL,
though these may be wanted later.
Essentially we can continue down the current path. Add a new
route that is useful but inconsistent with the rest of the API, and requires
the client to remember whether you need to list projects via either the
federation endpoint or the regular project list based on the token type.
None. All the information is currently available via existing APIs just in less convenient ways.
Other End User Impact¶
It simplifies things from a client perspective because you don’t need to know what sort of token you have to list projects/domains from. In general it simplifies receiving information regarding the current token, both the existing and anything we choose to expose in future.
Other Deployer Impact¶
This will hopefully make redundant the
/v3/OS-FEDERATION/domains endpoints. We may want to redirect requests from
there to the new endpoints.
- Primary assignee:
Create new routes for projects and domains, join federation and listing APIs.
Deprecate the corresponding OS-FEDERATION routes.
Expose this information via keystoneclient.
New APIs. Possibly some changes to the documentation regarding the standard workflow of scoping tokens.