You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Suresh Marru <sm...@apache.org> on 2014/03/17 20:51:07 UTC
[GSoC] Identity Server needs for Airavata
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
Re: [GSoC] Identity Server needs for Airavata
Posted by Suresh Marru <sm...@apache.org>.
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 <su...@gmail.com> 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 <sw...@gmail.com> 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 <sm...@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 <th...@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 <sm...@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
>
>
>
>
> --
> Thank you
> Supun Nakandala
> Dept. Computer Science and Engineering
> University of Moratuwa
Re: [GSoC] Identity Server needs for Airavata
Posted by Supun Nakandala <su...@gmail.com>.
Hi All,
I am working on a proposal for this project.
Thank you.
On Thu, Mar 20, 2014 at 10:20 AM, Sachith Withana <sw...@gmail.com>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 <sm...@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 <th...@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 <sm...@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
>
>
--
Thank you
Supun Nakandala
Dept. Computer Science and Engineering
University of Moratuwa
Re: [GSoC] Identity Server needs for Airavata
Posted by Sachith Withana <sw...@gmail.com>.
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 <sm...@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 <th...@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 <sm...@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
Re: [GSoC] Identity Server needs for Airavata
Posted by Supun Nakandala <su...@gmail.com>.
On Thu, Mar 20, 2014 at 9:59 AM, Suresh Marru <sm...@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 <th...@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 <sm...@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
Re: [GSoC] Identity Server needs for Airavata
Posted by Suresh Marru <sm...@apache.org>.
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 <th...@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 <sm...@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
>
Re: [GSoC] Identity Server needs for Airavata
Posted by Amila Jayasekara <th...@gmail.com>.
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 <sm...@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