airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Nakandala <supun.nakand...@gmail.com>
Subject Re: [GSoC] Identity Server needs for Airavata
Date Thu, 20 Mar 2014 10:41:07 GMT
On Thu, Mar 20, 2014 at 9:59 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.
>

Hi Suresh,
According to my knowledge, in Airavata we are not maintaining user accounts.
In Evernote, UserStore is used to manage user accounts. So what should be
the functionality of UserStore in the context of Airavata.


>
> 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
> >
>
>


-- 
Thank you
Supun Nakandala
Dept. Computer Science and Engineering
University of Moratuwa

Mime
View raw message