ADR - Project & Workflow Services - Core Services Integration - E&O

This ADR focuses on E&O rules from Project & Workflow Services point of view

Status

• Proposed
• Trialing
• Under review
• Approved
• Retired

Context & Scope

For Entitlements and Obligations, we have two options:

1. Coarse-grained access i.e. all users in a given Collaboration get the same level of access to all the data in the Collaboration. It is possible to have a set of "Viewer" users and "Owner" users who are allowed to Create/Update/Delete.
2. Fine-grained access i.e. full-fledged PBAC and RBAC on individual record level.

Option 1 will likely be the most appropriate for the PWS, as there are likely to be a relatively small number of users in a given Workspace. Also, during the course of the project, many temporary datasets will get created; managing the ACLs or Legal Tags (as in Option 2) of each will become cumbersome and superfluous.

Ingestion

This requires an "inheritance" notion for E&O to records from the parent Collaboration. Authorizations are currently implemented using ACLs or Legal Tags in records. To support E&O for PWS, we propose the following:

• Each Collaboration must have Legal Tags, Viewer ACL and Owner ACL assigned to it. This will have to be done during the creation of these entities. This also implies the need of APIs for the management of Collaboration
• To ingest data into a Collaboration, the x-collaboration header should be present in the request
• If the Record creation API sees the above header (implying the record belongs to a Collaboration), it must propagate the ACLs and LTs of the Collaboration, to the new record

Alternatively, we could adopt a dynamic approach where the ACLs/LTs of the Collaboration are checked whenever the Record is accessed. However, this is a much more far-reaching change that will impact a very large number of services. The above described simpler approach may be sufficient in our case as this data is of temporary value. The trade-off for this simplicity is that once the ACLs and LTs are assigned to the Collaboration, they cannot be modified.

Promotion

During Promotion or Publishing of Records to the SoR, the Ingestion process will need to assign ACLs and LTs afresh, because the ACLs and LTs assigned during project lifecycle may not be appropriate in the SoR.

Decision

Rationale

Consequences

• This is a non-breaking change
• As in the original ADR this functionality is enabled via the feature flag
• The ACL or LT of the Collaboration cannot be changed after creation
• Indexer-queue service's record change event processor should conform to Record Changed V2 format

When to revisit

---

Tradeoff Analysis - Input to decision

Alternatives and implications

Decision criteria and tradeoffs

Decision timeline