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 user_id 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 endpoints.
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 user_id.
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 GET v3/catalog 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.
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.
This will hopefully make redundant the /v3/OS-FEDERATION/projects and /v3/OS-FEDERATION/domains endpoints. We may want to redirect requests from there to the new endpoints.
New APIs. Possibly some changes to the documentation regarding the standard workflow of scoping tokens.