Gmartins/implement policy based authorization

Type of change

• Bug Fix
• Feature

Does this introduce a change in the core logic?

• [Yes]

Does this introduce a change in the cloud provider implementation, if so which cloud?

• AWS
• Azure
• GCP
• IBM

Updates description?

issue: #121 (closed)

This merge requests has the following objects:

• Add new authorization based on policy. With it the server can start with --authZ policyDelegate=URL, with delegate=URL the server will start with groups based authorization as before.
• New environment Variable AUTHORIZATION_MODE (simple or osdu, default is osdu)
  • osdu - etp-server will perform all record operations and authorization processes described by osdu
  • simple - in this mode the get/del/createDataspaceRecord any user is not allowed to use and the entitlement authorzation (service authorization) is skipped
• RecordsPath - path of the records. Default is /records
• New environment variable EVALUATE_POLICY_PATH (if the policyDelegate == authZURL then the request is sent to authZURL{EVALUATE_POLICY_PATH}), so do not forget the "/". Default is "/api/policy/v1/evaluations/query"
• The policy based authorization has the following permissions:
  • Create
  • Read
  • Update
  • Delete
• Implements the new DSPermission class to manage permissions. For each DSPermission we have 4 permission with cache expiration
  • If Create permission is cached, then we do not need to ask the delegate service the authorization for create
  • If the cache is expired, then a new request to delegate is made to ask if the user has the authorization
  • For each kind of permission is made a request to ask if the user is authorized for this permission
• If the server starts with --authZ policyDelegate=authZURL, then the policy based authorization will be used and has two variations:
  • 1. Authorization mode = osdu (default)
    • Entitlement.can(operation)Dataspace will request permission to "authZURL/api/entitlements/v2/groups" and will convert owner permission to all permissions policy or viewer permission into just read permission. The second authorization should come from dataspace entitlement "authZURL/api/policy/v1/evaluations/query"
    • entitlementDSClient.(create/del/get)DataspaceRecord sends the request to "storageURL{RECORDS_PATH}"
  • 2. Authorization mode = simple
    • Entitlement.can(operation)Dataspace the permission for entitlement service is always allowed and the permission from dataspace entitlement comes from "authZURL{EVALUATE_POLICY_PATH}"
    • entitlementDSClient.(create/del/get)DataspaceRecord ALWAYS return false (should not be used in simple mode)
    • entitlement.(un)registerDataspace ALWAYS return false (should not be used in simple mode)

The etp-server requires two authorizations:

1. Service authorization from entitlement service.
2. And operation authorization from policy service.

When in osdu mode the request for service authorization will be made for entitlementsURL/groups that will receive group based authorization. It is done since the OSDU entitlement service is based on groups only. If the user has OWNER permission, then it will be converted into CREATE/READ/UPDATE/DELETE permission (DSPermission with all permissions). Now if the user has VIEWER permission, then it will be converted into just UPDATE permission (DSPermission with just update permission). The second authorization made to policy service (which is already done, see api: https://community.opengroup.org/osdu/platform/security-and-compliance/policy/-/blob/master/docs/openapi.yaml?ref_type=heads). If not owner or viewer, then the user has no permission at all.

If the etp-server is running in simple mode, then the first authorization (service authorization) is not needed, i.e. the user has all permissions (for service only). The only authorization required is from policy service (dataspace authorization).

The Entitlement class is now a based class and has two derived classes:

1. EntitlementGroup for group based authorization (just like before)
2. EntitlementPolicy for policy based authorization (new one)

The entitlement class has two clients:

1. EntitlementClient is the client to deal entitlement service authorization. There are two variations for each type of authorization:

• EntitlementClient (group based)
• EntitlementClientPolicy (policy based) For now the EntitlementClientPolicy has an EntitlementClient variable to be able to get group based authorization. This is temporary while the entitlement service is not able to deal policy based authorization.

2. EntitlementDataspaceClient is the client to deal entitlement dataspace authorization. There are two kinds as well:

• EntitlementDataspaceClient (group based)
• EntitlementDataspaceClientPolicy (policy based)

Both Entitlement and DataspaceEntitlement makes use of the class DSPermission. This class contains and manager the permissions itself. Each DSPermission instance has the authorization for CREATE/READ/UPDATE/DELETE operations. When the entitlement receives the permission for an operation (or operations), it adds the permission into DSPermission instance and this authorization is cached during a certain among of time (current time is 5 minutes). After this time the entitlement service needs to check the authorization again and add the permission again into the DSPermission.

STORAGE_URL and ENTITLEMENT_URL definition: Is authZURL empty?

• true:
  • storage_url = $ENV{STORAGE_URL} (or config)
  • entitlement_url = $ENV{ENTITLEMENT_URL} (or config)
• false:
  • if $ENV{STORAGE/ENTITLEMENT_URL}(or config) is empty or is "osdu-pattern" or not a path (does not start with '/')
    • storage_url = authZ/api/storage/v2
    • entitlement_url = authZ/api/entitlements/v2
  • otherwise
    • storage_url = authZ{STORAGE_URL}
    • entitlement_url = authZ{ENTITLEMENT_URL}