You are viewing a plain text version of this content. The canonical link for it is here.
Posted to custos@airavata.apache.org by Isuru Ranawaka <ir...@gmail.com> on 2020/03/17 14:45:15 UTC
Custos Group Implementation
Hi all,
I have come up with an initial idea of implementing Groups in Custos [1].
Based on Groups we can do API authorization, Distributed Agent
authentication (e.g MFT), probably HTRC Data Capsule authentication.
Please go through it if you find time and comment, add use cases as needed.
[1]
https://docs.google.com/document/d/1QtUKTfAnIrErvtYnKo3FizCRL2GUiWikEzvBnHPXfWw/edit#heading=h.pvwzdvihmpkk
thanks
Isuru
--
Senior Engineer
WSO2 Lanka (pvt) Ltd
Blog:- http://isurur.blogspot.com/
Phone:- +94714629880
Re: Custos Group Implementation
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Marcus,
that helps a lot.
thank you.
On Mon, Mar 23, 2020 at 8:40 PM Christie, Marcus Aaron <ma...@iu.edu>
wrote:
> Hi Isuru,
>
> On Mar 21, 2020, at 11:42 AM, Isuru Ranawaka <ir...@gmail.com> wrote:
>
>
> 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.
>
>
> Yes, it is just that. Before with role based API access a user needed to
> have a certain role to call some API methods. With resource level
> authorization, any user can call the method but the user needs to have the
> right permission for that resource.
>
> For example, we have API methods to get/create/delete credential store
> tokens. In the old approach only users with role 'admin' could even call
> those methods. Now all users can call those methods, but each method checks
> that the user has the appropriate READ (for "get" methods) or WRITE (for
> delete methods) permission for the given credential store token. (for
> example: deleteSSHPubKey [1])
>
> I hope that helps.
>
> Thanks,
>
> Marcus
>
> [1]
> https://github.com/apache/airavata/blob/master/airavata-api/airavata-api-server/src/main/java/org/apache/airavata/api/server/handler/AiravataServerHandler.java#L821
>
>
--
Senior Engineer
WSO2 Lanka (pvt) Ltd
Blog:- http://isurur.blogspot.com/
Phone:- +94714629880
Re: Custos Group Implementation
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
Hi Isuru,
> On Mar 21, 2020, at 11:42 AM, Isuru Ranawaka <ir...@gmail.com> wrote:
>> 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.
Yes, it is just that. Before with role based API access a user needed to have a certain role to call some API methods. With resource level authorization, any user can call the method but the user needs to have the right permission for that resource.
For example, we have API methods to get/create/delete credential store tokens. In the old approach only users with role 'admin' could even call those methods. Now all users can call those methods, but each method checks that the user has the appropriate READ (for "get" methods) or WRITE (for delete methods) permission for the given credential store token. (for example: deleteSSHPubKey [1])
I hope that helps.
Thanks,
Marcus
[1] https://github.com/apache/airavata/blob/master/airavata-api/airavata-api-server/src/main/java/org/apache/airavata/api/server/handler/AiravataServerHandler.java#L821 <https://github.com/apache/airavata/blob/master/airavata-api/airavata-api-server/src/main/java/org/apache/airavata/api/server/handler/AiravataServerHandler.java#L821>
Re: Custos Group Implementation
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Marcus,
On Thu, Mar 19, 2020 at 7:05 PM Christie, Marcus Aaron <ma...@iu.edu>
wrote:
> Hi Isuru, comments below inline
>
> On Mar 17, 2020, at 12:00 PM, Isuru Ranawaka <ir...@gmail.com> 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
Re: Custos Group Implementation
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
Hi Isuru, comments below inline
> On Mar 17, 2020, at 12:00 PM, Isuru Ranawaka <ir...@gmail.com> 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.
Re: Custos Group Implementation
Posted by Isuru Ranawaka <ir...@gmail.com>.
Hi Dimuthu,
Useful comments to further think through this. Please find my inline
comments.
On Tue, Mar 17, 2020 at 10:59 AM DImuthu Upeksha <di...@gmail.com>
wrote:
> Hi Isuru,
>
> I have few comments and questions.
>
> 1. Are there 2 group backends to the User/Group core service (Database /
> Keycloak) or is Keycloak is the only group backend? How does the Airavata
> group based auth plugin with this?
>
There are two group representations in the Keycloak level and the Custos
local database. We can create hierarchical Groups in Keycloak. Child Groups
and Users inherit Roles assigned to parent Groups. So roles assigned to
Groups are automatically embedded into ID or Access Tokens of Users. Hence,
at the Gateway level, we can decode the tokens and check for the roles
users are assigned. We need to maintain Role to API Mapping at the Gateway
level and based on that mapping Gateway can decide to accept or deny the
request.
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.
Local database for Groups is maintained to add metadata information and
store extra data related to SCIM specifications.
> 2. How do you plan to bind permissions between agents and resources? For
> example, agent 1 should be able to access all files in comet server path
> /home/user1 but should not be allowed to access rest of the resources.
>
I still did not think about authorizing agents to the resource server. But,
a rough idea would be group resource paths into particular roles and add
those roles to the Access Tokens of agents. Based on the access token
capabilities, the resource server can grant agents. In this case, also we
need to have a central controller for agents. Need to further investigate
this.
> 3. In below diagram, agent should have 2 tokens. User level token as
> illustrated in the diagram and agent level token with refresh which
> identifies the agent itself. Using that token we can whitelist/ blacklist
> agents talking to secure services.
>
The idea would be Gateway does not forward User Access Tokens to agents.
Gateway keeps User AT with itself for security reasons. Exposing User ATs
to agents may cause to leak User information to outside. Hence, The Gateway
fetches and short-lived AT for selected agent and this AT has a short
lifetime compared to User AT with a limited set of information (authorized
roles and attributes for agent). The agent should verify this token by
decoding it and check for relevant roles and attributes before proceeding.
If that check passed then the agent can request data required to access
remote resources from Custos. Custos again validates the agent AT and
claims send by an agent to validate agent and if all conditions are met
data will be released.
These tokens are dynamic hence, we can't use them from static bindings. but
we can embed static information such as agentId into tokens to do the
binding.
thanks
Isuru
>
>
> Thanks
> Dimuthu
>
> On Tue, Mar 17, 2020 at 10:45 AM Isuru Ranawaka <ir...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I have come up with an initial idea of implementing Groups in Custos [1].
>> Based on Groups we can do API authorization, Distributed Agent
>> authentication (e.g MFT), probably HTRC Data Capsule authentication.
>> Please go through it if you find time and comment, add use cases as needed.
>>
>>
>> [1]
>> https://docs.google.com/document/d/1QtUKTfAnIrErvtYnKo3FizCRL2GUiWikEzvBnHPXfWw/edit#heading=h.pvwzdvihmpkk
>>
>> thanks
>> Isuru
>>
>>
>>
>> --
>> Senior Engineer
>> WSO2 Lanka (pvt) Ltd
>> Blog:- http://isurur.blogspot.com/
>> Phone:- +94714629880
>>
>
--
Senior Engineer
WSO2 Lanka (pvt) Ltd
Blog:- http://isurur.blogspot.com/
Phone:- +94714629880
Re: Custos Group Implementation
Posted by DImuthu Upeksha <di...@gmail.com>.
Hi Isuru,
I have few comments and questions.
1. Are there 2 group backends to the User/Group core service (Database /
Keycloak) or is Keycloak is the only group backend? How does the Airavata
group based auth plugin with this?
2. How do you plan to bind permissions between agents and resources? For
example, agent 1 should be able to access all files in comet server path
/home/user1 but should not be allowed to access rest of the resources.
3. In below diagram, agent should have 2 tokens. User level token as
illustrated in the diagram and agent level token with refresh which
identifies the agent itself. Using that token we can whitelist/ blacklist
agents talking to secure services.
Thanks
Dimuthu
On Tue, Mar 17, 2020 at 10:45 AM Isuru Ranawaka <ir...@gmail.com> wrote:
> Hi all,
>
> I have come up with an initial idea of implementing Groups in Custos [1].
> Based on Groups we can do API authorization, Distributed Agent
> authentication (e.g MFT), probably HTRC Data Capsule authentication.
> Please go through it if you find time and comment, add use cases as needed.
>
>
> [1]
> https://docs.google.com/document/d/1QtUKTfAnIrErvtYnKo3FizCRL2GUiWikEzvBnHPXfWw/edit#heading=h.pvwzdvihmpkk
>
> thanks
> Isuru
>
>
>
> --
> Senior Engineer
> WSO2 Lanka (pvt) Ltd
> Blog:- http://isurur.blogspot.com/
> Phone:- +94714629880
>