Review API-Guidelines: Module isolation

[cgendreau]

APIs should not talk to each other.

To keep microservices simple and quick, they should only serve what they are responsible for and avoid calling another API to supplement the data. The caller of the module should be responsible for that. If at some point it becomes impossible or unmanageable, a "composed" API should be created.

Distributed transaction will not be supported.

[dshorthouse]

How might roles and permissions interact with this constraint when a session may need to be used to hide some attributes in a single model but not others?

For example, some users may have a role that grants them permission to access some details of an acquisition such as number of lots or specimens and their condition but for legal reasons, that same role does not have permission to view the financial details of the acquisition. In a rapid data entry interface (= single page) in support of a digitization workflow, there may be a number of API calls to many disparate modules. Not all attributes should be included nor discoverable in such async JSON API responses regardless of whether or not they are used to build a particular UI element.

Is that what you mean by a "composed" API? One that would act as a wrapper to accommodate roles and permissions by stripping off attributes from source API responses as needed? Here is where we'll need some stress testing.

[cgendreau]

Some discussion on #40

[gnewton]

I believe David's example is quite compelling. We have discussed this situation in the past. I think this could be solved using a spectrum of solutions (all that require some module(s) to make calls to the Auth API (an exception to the rule):

1. The module makes a call to the Auth API and filters its own response. Advantages: More performant; No API change; Disadvantages: All modules call Auth API; underlying module implementation more complex
2. An proxy layer (API) that is a proxy module, and it acts as a filter on the response, based on authorization derived from a call to the Auth API. Advantages: Simple to implement; same API as original module API; simplicity means lower impact on performance; only proxy calls Auth API; can be implemented after core modules. Disadvantages: Additional modules (although all proxying could be implemented through a single proxy module); more complexity for deployment; all proxy modules call Auth API
3. An orchestration layer, that makes calls to (perhaps) multiple calls to the underlying modules, and creates a union response. Advantages: Pushes API call fanout closer to modules; Single call by client; possibly single call to Autth API. Disadvantages: Different API; more complex implementation; if modules are not all at same deployment location, makes deployment more complex

I prefer number 2, proxy-per-module, with a single module implementing proxying for all modules. Its first implementation could be a pass-through proxy (i.e it just calls the underlying modules).

[cgendreau]

If the technology used for a module has Keycloak support (e.g. Spring Keycloak Adapter) the authentication and roles are available to all modules (SSO). I think modules should enforced authorization based on the group/role(s) received so it could send back only what is appropriate.

This is important since DINA modules are multi-tenant and we can't simplify base access on URLs like /protected. The group/role has to propagate to the database query to only query what the user has access to. (In Short, Option 1)

[dshorthouse]

I have a feeling this is going to be a ropy problem & the solution will undoubtedly emerge the moment data must be pulled simultaneously from two modules while honouring expressions of permission from both.

I think we can safely assume that roles should be defined in a single place in DINA: admin, volunteer, collection manager, etc. whatever. But for practical reasons, permissions ought to reside closer to (if not within) modules because each of their schema will be unstable by varying degrees, especially during active development. And, the JSON-APIs that reach into these modules will be versioned as a result. A proxy API would require some knowledge of the attributes (and perhaps their values) fed to it from underlying JSON-API responses and would expect these attributes to remain stable. That's a tall order for integration tests let alone developers.

The fundamental issue then is how do we make permissions defined in modules listen nicely to what's asked of them by a central broker that defines roles AND coordination of all this through sessions is sufficiently secure to prevent escalation even though ALL the attributes in a module should be knowable.

Some discussion here that concurs with @cgendreau https://dzone.com/articles/authentication-and-authorization-in-microservices

[cgendreau]

I think we can safely assume that roles should be defined in a single place in DINA

I would say yes, in Keycloak with a combination of group (the collection for example) and roles (admin). The group will be used to map with objects "owner". Easiest example is to get the list of all samples that I can see (GET /sample) which translated in all the samples where the owner is one of my groups.

Keycloak does Authentication, adds roles/groups in the JWT and pass it to the module. The module can validate the "claims" using Keycloak Adapter and use the information to allow or reject operations.