Hi Isuru, comments below inline > On Mar 17, 2020, at 12:00 PM, Isuru Ranawaka <[email protected]> wrote: > > AFAIK, current API authorization is done by getting Users Groups and check > for each group whether it has access to a particular API. So it has Group > to API Mapping and Group representation at the Gateway level. In the above > scenario, Group representation moved to the Custos level and mapping needs > to be kept at the Gateway level.
The Airavata API authorization is in something of a transitional state. We were doing role based access to API methods. For much of the API we are now doing resource level authorization using the Sharing API. So for example, a client calls getExperiment(authToken, experimentId) and the API server checks the Sharing API to see if the user has READ permission for that experiment. However, some methods are only available to admin users and for these there is a maintained mapping of methods that require membership in the Admins group (or Read Only Admins groups for access to read only admin methods). My hope was that eventually we move to resource level authorization for all API methods and away from role/group based access to API methods.
smime.p7s
Description: S/MIME cryptographic signature
