Hi Supun, You might find this useful and relevant - http://dev.evernote.com/doc/articles/authentication.php
Suresh On Mar 20, 2014, at 2:37 AM, Supun Nakandala <[email protected]> wrote: > 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
