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

[ga4gh]

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

[junjun-zhang]

@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.

[mdmiller53]

@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

[brucehoff]

@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?

[geoffjentry]

@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.

[jaeddy]

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.

[patmagee]

@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

[jaeddy]

@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.