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 >
