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 <[email protected]> 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 <[email protected]> > 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
