ADR: Set User Details and Allow Use in Policies

Status

  • Proposed
  • Trialing
  • Under review
  • Approved
  • Retired

Context

OSDU has adopted Rego as the language to define policies and Open Policy Agent as an internal solution to manage and enforce the policies. To enforce a policy, various OSDU services call policy service which internally calls OPA API. Some services (storage) bypass policy service and make low level calls to OPA directly.

Today if you want to potentially limit access to records in OSDU by region/country you have have to use http.send(request) to an external service. While this could potentially work as a solution, however it causes issues at scale due to latency and becomes very complicated to manage authentication between OSDU and non-OSDU systems.

This proposal will simply optionally add the ability to store location for user by country (or lat & long). This could then be accessed within policies moving forward.

Scope

Implement new user APIs to manage details about users. In particular country setting for user. Provide documentation how to use (with example policies) and documentation how to use optional functionality.

Solution

Update the Policy Service adding in APIs to manage additional user details. At first this will just be country for user but this design allows future expansion of these details so they could be used in future policies.

APIs:

  • PUT /api/policy/v1/user/{user_id} - sending user details which include country code (can only be called by service.policy.useradmin a higher-privileged role and not the user themselves). Optional TTL parameter.
  • GET /api/policy/v1/user/{user_id} - retrieve user details which include country code (can be called by policy user)
  • DELETE /api/policy/v1/user/{user_id} - Delete user details

Consequences

Policy service will need to store these user details (including country location data) in highly available fast location. This proposal is to store it in Redis (which is already used in OSDU). However a mapper/driver layer will be implemented to allow CSPs to build a solution other than redis in the future. Policy service will need to be granted access to Redis. A new entitlement group will also be needed.

Policy Service will need to be provided:

  • Redis connection details (endpoint, auth)
  • Access to allow policy service to connect to Redis
  • A new entitlement group. Proposed name policy.service.useradmin

Optional Usage

  • These new APIs usage would be optional and there would be no proposed changes to default policies.
  • Not providing the endpoint for redis to policy service would disable the new APIs.
  • The location data has a TTL, which is also configurable via the PUT APIs.

Design Architecture

image

Edited by Shane Hutchins