Hi Aarushi, If you ave questions on authentication grant flows and its application to gateways, this paper has some description - https://scholarworks.iu.edu/dspace/bitstream/handle/2022/21092/airavata-security-escience16.pdf <https://scholarworks.iu.edu/dspace/bitstream/handle/2022/21092/airavata-security-escience16.pdf>
Also OAuth2 spec describes the flows well - https://tools.ietf.org/html/rfc6749#page-23 <https://tools.ietf.org/html/rfc6749#page-23> Suresh > On Aug 20, 2019, at 10:27 AM, Suresh Marru <[email protected]> wrote: > > Hi Aarushi, > > Thank you for the detailed update. Looks like Marcus’s response addressed > your queries, I will echo them: > > I agree with Marcus the sharing and group services are inherently coupled but > as you said it will helpful to facilitate use of group capabilities without > necessarily having to use sharing. So + 1 for keeping them in one service but > exposing group only API’s to go along with User Profile API’s. > > + 1 for OAuth2 Client Credentials as an authentication mechanism between > Gateways and Custos. Since Gateways are hosted on a secured services, this > might work well. > > + 1 for Airavata proxy API’s for Custos functionality. This might help > preserve usability of Airavata API’s while allowing independent use of Custos > Services. > > Suresh > >> On Aug 19, 2019, at 5:09 PM, Christie, Marcus Aaron <[email protected]> wrote: >> >> Thanks for the update Aarushi. Replies inline: >> >> On 8/18/19, 6:25 PM, "Bisht, Aarushi" <[email protected]> wrote: >> >> 1. ??Group Service Migration:??? This service is tightly coupled with >> the airavata sharing registry service. Since sharing service will also be >> migrated to custos, I could defer the migration of group service until the >> migration of sharing service while keeping the dependency between these 2, >> or, I could decouple this dependency and make group service an independent >> service. We might need independent group service if we are allowing other >> Gateways to use only Custos authentication and profile service while >> implementing their own sharing service. What are our plans regarding this? >> >> >> The GroupManagerService essentially just adds authentication on the group >> functionality in the sharing service. I think they are inherently coupled. >> I'm assuming Custos will need some similar public API to its functionality. >> >> >> 2. Integration of Custos with Airavata: There are couple of discussions >> that I wanted to bring up: >> >> * ? Authentication between Gateways and Custos : As of now, I have not >> implemented any authentication/authorization between these 2 services. Do we >> need this or would we rely on network and firewall based limited access to >> custos servers? If we do need it, I would appreciate suggestions on type of >> authentication to use. >> >> >> Since Custos will be potentially consumed by multiple non-Airavata gateways, >> I think it needs to authenticate/authorize calls. For service-to-service >> type calls my initial thought is to use OAuth2 client credentials. >> >> >> * ??Airavata proxying Custos services: Since the portals using >> Airavata should not be impacted with the migration of some of Airavata >> services, the Airavata APIs will essentially be proxying Custos services in >> some cases. For example the Airavata APIs for user creation,deletion, >> updation will remain the same but most of the business logic and database >> will be in Custos. Airavata will only keep user/tenant information specific >> to itself. So essentially, Airavata is just proxying Custos. This is true >> for most of the APIs which rely on Custos. >> >> >> I think proxying from the Airavata services to Custos sounds like a good >> idea. >
