Retrieve Authentication Scoped Data

bp auth-specific-data

We need routes that allow us to retrieve information relevant to the current authentication scope.

Problem Description

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.

Proposed Change

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.

  • Create 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/projects in favour of this.

  • Create 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/domains in 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 user_id.

Currently I am not proposing to add POST or modifying routes to the URL, though these may be wanted later.

Alternatives

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.

Security Impact

None. All the information is currently available via existing APIs just in less convenient ways.

Notifications Impact

None.

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.

Performance Impact

None.

Other Deployer Impact

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.

Developer Impact

None.

Implementation

Assignee(s)

Primary assignee:

jamielennox

Other contributors:

Work Items

  • Create new routes for projects and domains, join federation and listing APIs.

  • Deprecate the corresponding OS-FEDERATION routes.

  • Expose this information via keystoneclient.

Dependencies

Documentation Impact

New APIs. Possibly some changes to the documentation regarding the standard workflow of scoping tokens.

References

None.