Hi All, I am working on a proposal for this project.
Thank you. On Thu, Mar 20, 2014 at 10:20 AM, Sachith Withana <[email protected]>wrote: > This sounds like a really good project from which Airavata would benefit a > lot ( seeing the complications we have on the thrift security issues). > > Using either the use case 1 or the use case 3, the Cybergateway would also > be able to support the user authentication and authorization. > > > On Thu, Mar 20, 2014 at 12:29 AM, Suresh Marru <[email protected]> wrote: > >> Thanks Amila for the offline chat on this topic. Let me summarize our >> conversation. >> >> There are three basic use cases for Airavata: >> >> Use Case1: Airavata Client (lets say Gateway 1) has its own user store >> and would like to interact with Airavata Server to do secure communications >> Use Case2: Airavata Client (lets say Gateway 2) uses open-id like third >> part authentication and would like to interact with Airavata Server to >> delegate computations. >> Use Case3: Airavata Client (lets say Gateway 3) does not have any user >> store and expects Airavata to provide identity management. >> >> Amila's recommendation is not to bundle a user store with Airavata and >> for use case 3 suggest to deploy a third part identify server such as WS02 >> Identity server (which is open source with Apache License). >> >> So this means we boil down to Airavata Clients doing their own >> authentication either by a built in user store, or delegated to a open id >> like provider or deploying a third part IS. Airavata will then have to >> assume for all the use cases, the authentication is already done and enable >> authorization through a token for every request. >> >> Before we jump into a conclusion here are the possible solutions for the >> above use cases: >> >> Use Case 1: >> * Mutual Authentication - this seems to be most easy on implementation >> but might have operational inconveniences. >> * One way SSL + sign in with a user-password - this seems to have >> security implications on sharing the user name passwords. >> * Shared Secret - this is a good viable solution, as long as this secret >> (token) is short lived and have proper expiration and revocation policies. >> >> Use Case 2: >> * If the third party identity provider has OAuth 2.0 support, then the >> Client sends a token which Airavata uses to contact the OAuth server to >> retrieve user information >> * if the third part IS does not have OAuth then an additional service >> needs to be developed to use a secured token service coupled with IS >> typically with a HTTPS access. >> * OpenID Connect enabled IS could potentially be viable here to provide >> authorization in addition to authentication. >> >> Use Case 3: >> * Suggest third party IS or use of kerberos. >> >> For Airavata GSoC project, it will be good to explore Evernote security >> [1] and follow similar strategy of obtaining a API Key (during gateway >> registration process) and use it for all further communications. The >> authorization itself has to be similar to what Evernote uses a separate >> UserStore Service [2] which is run separately then the note store service >> [3]. The thrift mailing list and Airavata Architecture list might provide >> better guidance on this topic. >> >> Suresh >> [1] - http://dev.evernote.com/ >> [2] - >> https://github.com/evernote/evernote-thrift/blob/master/src/UserStore.thrift >> [3] - >> https://github.com/evernote/evernote-thrift/blob/master/src/NoteStore.thrift >> >> On Mar 17, 2014, at 4:14 PM, Amila Jayasekara <[email protected]> >> wrote: >> >> > Hi Suresh, >> > >> > I need to think about this in detail. I will send you a detail reply >> later. >> > It seems this is going to be an interesting idea. >> > >> > Thanks >> > Amila >> > >> > >> > On Mon, Mar 17, 2014 at 3:51 PM, Suresh Marru <[email protected]> >> wrote: >> > Hi All, >> > >> > I would like to brainstorm on this project idea. I know it may be too >> late for GSoC, but still if we conclude enough, we can probably motivate a >> student to pick on it. >> > >> > For Airavata thrift API, we have been relying on a assertion of mutual >> authentication with client gateways. This still seems reasonable, but I >> worry about deployment headaches of issuing and managing these PKI's. More >> over, when Sachith had a brief interaction on this topic on thrift dev list >> [1], it seems like mutual authentication is not current available. The >> service authentication seems to be well supported though. >> > >> > Since Airavata based gateways at some point will need to work on >> Identity Management, I wonder if prototyping a OAuth2 identify server >> integration with Airavata might help? If this is worth exploring, making >> this a GSoC idea might not be a bad choice. >> > >> > Amila and others, any thoughts? >> > >> > Suresh >> > [1] - http://markmail.org/thread/3ukgiznbmvi6g5vd >> > >> >> > > > -- > Thanks, > Sachith Withana > > -- Thank you Supun Nakandala Dept. Computer Science and Engineering University of Moratuwa
