airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachith Withana <swsach...@gmail.com>
Subject Re: [GSoC] Identity Server needs for Airavata
Date Thu, 20 Mar 2014 04:50:17 GMT
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 <smarru@apache.org> 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 <thejaka.amila@gmail.com>
> 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 <smarru@apache.org> 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

Mime
View raw message