workflow-execution-service-schemas icon indicating copy to clipboard operation
workflow-execution-service-schemas copied to clipboard

Clarify how the WES API is used by multiple, independent users sharing a back end

Open brucehoff opened this issue 6 years ago • 5 comments

Approaches might include:

  1. No fine-grained authorization: Anyone who can access a WES compliant workflow engine has access to all the workflows in that system;
  2. All WES APIs require authentication and the authorized user has access to just the workflow that they created. When a user asks to 'list all workflows' the list includes just the ones they created;
  3. Users can share access to workflows they create with other users. This may require additional APIs in WES or, alternatively, access control could be deemed out-of-scope for WES.

brucehoff avatar Mar 26 '18 21:03 brucehoff

@brucehoff, as I understand WES API does intend to be used by multiple users. As shown in the current Swagger specification, here is an example of ErrorResponse for unauthorized operation. So, I think it's clear that there should be an authentication/authorization process before a user can call the API endpoints properly.

Indeed, it could be more explicitly documented. Perhaps for example, in this /workflows GET operation, the summary could add something more specific that only workflows are authorized for the current user will be returned.

I feel the same way that access control could be left to the implementers to decide how to handle, and WES specification should be focused on core functionalities.

junjun-zhang avatar Apr 07 '18 23:04 junjun-zhang

@brucehoff in an implementation i did, i tried a layered approach. the workflow engine ran on a server, it took requests to start workflows and returned a token that could be used to access that workflow through that workflow API. whoever called to start the workflow then was responsible for managing that workflow through the token. so on a different server i implemented a workflow 'user' task, potentially multiple user servers could then use that workflow server

mdmiller53 avatar Jun 11 '18 17:06 mdmiller53

@mdmiller53 under your approach I wonder how the 'list all workflows' API would work. E.g., if there are 100 workflows running, but just 5 for you (and so you have 5 'tokens') then are you able to 'list all workflows' and see just your 5? How you pass the 5 tokens via HTTP?

brucehoff avatar Jun 11 '18 17:06 brucehoff

@brucehoff @mdmiller53 You'd need to return just the 5. The GA4GH security group is in the process of speccing out an authn/authz scheme which we'll be expected to fold into WES.

geoffjentry avatar Jun 12 '18 14:06 geoffjentry

After a number of discussions, it seems that multitenancy with WES can be enabled through a variety of configurations. While these different scenarios don't necessarily need to be included in the spec, we should provide examples in the documentation.

jaeddy avatar May 02 '19 23:05 jaeddy

@jaeddy can we close this as something that is up to the implementor and not specifically needed in the spec? there is general terminology currently in the spec about seeing only runs a user has access to, but I would be hesistant to have stronger language around multi-tenancy then that

patmagee avatar Sep 22 '22 09:09 patmagee

@patmagee I think that makes sense. This feels more in the domain of the starter kit efforts, and could eventually make its way into WES documentation (user guides, tutorials, etc.), but I don't see a strong need for having it be part of the spec.

jaeddy avatar Sep 22 '22 09:09 jaeddy