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.
