Page Comparison

(Related to

Problem Description

There is a need for a service's API endpoints to allow special access that cannot be sufficiently described using rights. A couple of examples:

...

The main impetus in particular for this research is how to allow access to reference data in the Reference Data Service.

Possible Approaches

1. Allow read-only access to only authenticated users - users would be able to view (reference) data, but would not be able to change it. Viewing data would be allowed for any logged in user.
   
   1. For the system rights example, the mechanism to disallow changing other reference data would have to disallow access to all rights endpoints.
   2. Con: there seems to be a security issue. While the endpoints are not public to the world (which would be a non-starter) so the endpoints require some authentication, allowing anyone in the system to view all of the data seems like a security breach.
   3. Con: this doesn't address the notification service example–how would a user be able to create a new notification to be processed?
2. Add private versions of all endpoints that would be used by services
   1. Pro: this does address all examples. Users who would need to access endpoints could access the public one, while services would access the private ones. Any endpoints that should not be called by a user would not have a public version of the endpoint.
   2. Con: this seems like it would double the number of endpoints to maintain.
   3. How would we ensure these endpoints are "private"?
   4. Would we really want to create private versions of all endpoints for all services? If not, we would still need to determine which endpoints to have private versions
3. Differentiate access tokens between service and user - any access token passed to an endpoint would be checked with the auth service to see if it's a service-based token or a user-based token
   1. Pro: this does address all examples. A service would have the credentials to generate a service-based token. Any service that needs to check if a token is service-based (or user-based) could consult the auth service to check and allow or deny accordingly.
   2. There is some complexity here to have different token types and for services to consult the auth service to check the type. But this might not be much complex than the current auth implementation.

Chosen Approach and Design

Option number 3 was chosen as it seems to have the fewest drawbacks while satisfying the requirements.

A small spike with some proof-of-concept code was done in the Auth and Reference Data Services to see how it could be implemented for different scenarios. (This code can be found in the feature/OLMIS-1456-service-level-rights branches of the two repositories.) It was found that the main OAuth client credentials used to generate access tokens could be used to generate only service-level access tokens once the password grant_type is removed. Then, an additional OAuth client with its own credentials was created to generate user-based access tokens.

...