Hi Marcus, On Thu, Mar 19, 2020 at 7:05 PM Christie, Marcus Aaron <[email protected]> wrote:
> 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. > > I thought permissions(read, write) for Resources (experiments, experiment outputs, projects) are managed through Groups. That means Resources are shared with Groups and based on Group membership users are granted to Resources. Can you explain bit more about resource level authorization. -- Senior Engineer WSO2 Lanka (pvt) Ltd Blog:- http://isurur.blogspot.com/ Phone:- +94714629880
