You are viewing a plain text version of this content. The canonical link for it is here.
Posted to architecture@airavata.apache.org by Marlon Pierce <ma...@iu.edu> on 2014/06/03 08:33:50 UTC
Thrift API security and desktop clients
This email is intended to introduce some security discussion.
One of the advantages of Thrift is the ability it will give us to
integrate native-language SDKs with desktop clients. This requires
though that we will need to think through our security model. In the
usual browser-based use case, the user does not make direct calls to the
API. These come instead from the gateway server, and we can establish a
trust relationship (such as SSL mutual authentication).
For the desktop client case, users make direct calls to the Airavata API
server, so we have three actors: the desktop application, the API
Server, and an auth service. The Auth service performs initial
authentication of the user; it is a service that is gateway-dependent.
Without going into too many details, OAuth is the usual protocol for
doing this. Evernote, in their Thrift API, provides this as an option.
Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
does this mean we need to implement OAuth ourselves?
Thrift also has a different use case in that they are not a
multi-tenanted service: they own all the accounts that they
authenticate. In contrast, a single Airavata server may support several
unrelated gateways. Each gateway would manage its own user accounts.
What are the best options for Airavata?
Marlon
Re: Thrift API security and desktop clients
Posted by Marlon Pierce <ma...@iu.edu>.
Hi Samir--
Thanks for delurking and the OAuth pointers. The server is in Java, and
Spring is definitely overkill.
Marlon
On 6/4/14 12:48 AM, Samir Faci wrote:
> I'm presuming the server code base is in java. (I've been lurking on
> here but haven't chatted much). But if you are going the OAuth route
> there are tons of
> existing libraries in a variety of languages that you can pull in.
>
> http://oauth.net/code/
>
>
> For java specifically,
>
> https://code.google.com/p/oauth/
>
> or
> https://code.google.com/p/oauth-signpost/
>
> would work well. Spring also has a library, though Spring is usually
> overkill unless you have other features from spring that you
> want/need.
>
>
>
> On Tue, Jun 3, 2014 at 10:59 AM, Randy Heiland <he...@iu.edu> wrote:
>> Fwiw, here’s the draft document I mentioned below:
>> http://pages.iu.edu/~heiland/ctsc/BestPracticesforThriftClients_EvernoteUseCase.pdf
>>
>> I’d welcome any comments people might have.
>>
>> -Randy
>>
>> On Jun 3, 2014, at 9:05 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>>> Hi Randy--
>>>
>>> Yes, I mean "Evernote" in the next to the last paragraph--Evernote does
>>> not have the same mulitenanted use case.
>>>
>>> I'm looking forward to your document, but I'm also at a conference this
>>> week and want to have a few thoughts in mind for my presentation in case
>>> anyone is interested.
>>>
>>> Marlon
>>>
>>> On 6/3/14 11:00 AM, Randy Heiland wrote:
>>>> Marlon,
>>>>
>>>> In your last paragraph, you mean “Evernote...” and not “Thrift also has…” - correct?
>>>>
>>>> I believe you’re correct in your Thrift over HTTP for Evernote assumption, based on this:
>>>> http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/201005.mbox/%3Ch2pc543765d1005031615t9b3e4a59ic77261d5b7bc08d3@mail.gmail.com%3E
>>>>
>>>> I actually have a doc to share with your team shortly regarding Evernote/Thrift that we did as part of our (CTSC) engagement with you. And I have some follow-on questions that I’ll contact you about offline.
>>>>
>>>> -Randy
>>>>
>>>> On Jun 3, 2014, at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>>>
>>>>> This email is intended to introduce some security discussion.
>>>>>
>>>>> One of the advantages of Thrift is the ability it will give us to
>>>>> integrate native-language SDKs with desktop clients. This requires
>>>>> though that we will need to think through our security model. In the
>>>>> usual browser-based use case, the user does not make direct calls to the
>>>>> API. These come instead from the gateway server, and we can establish a
>>>>> trust relationship (such as SSL mutual authentication).
>>>>>
>>>>> For the desktop client case, users make direct calls to the Airavata API
>>>>> server, so we have three actors: the desktop application, the API
>>>>> Server, and an auth service. The Auth service performs initial
>>>>> authentication of the user; it is a service that is gateway-dependent.
>>>>> Without going into too many details, OAuth is the usual protocol for
>>>>> doing this. Evernote, in their Thrift API, provides this as an option.
>>>>>
>>>>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>>>>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>>>>> does this mean we need to implement OAuth ourselves?
>>>>>
>>>>> Thrift also has a different use case in that they are not a
>>>>> multi-tenanted service: they own all the accounts that they
>>>>> authenticate. In contrast, a single Airavata server may support several
>>>>> unrelated gateways. Each gateway would manage its own user accounts.
>>>>>
>>>>> What are the best options for Airavata?
>>>>>
>>>>>
>>>>> Marlon
>>>>>
>
>
Re: Thrift API security and desktop clients
Posted by Samir Faci <sa...@esamir.com>.
I'm presuming the server code base is in java. (I've been lurking on
here but haven't chatted much). But if you are going the OAuth route
there are tons of
existing libraries in a variety of languages that you can pull in.
http://oauth.net/code/
For java specifically,
https://code.google.com/p/oauth/
or
https://code.google.com/p/oauth-signpost/
would work well. Spring also has a library, though Spring is usually
overkill unless you have other features from spring that you
want/need.
On Tue, Jun 3, 2014 at 10:59 AM, Randy Heiland <he...@iu.edu> wrote:
> Fwiw, here’s the draft document I mentioned below:
> http://pages.iu.edu/~heiland/ctsc/BestPracticesforThriftClients_EvernoteUseCase.pdf
>
> I’d welcome any comments people might have.
>
> -Randy
>
> On Jun 3, 2014, at 9:05 AM, Marlon Pierce <ma...@iu.edu> wrote:
>
>> Hi Randy--
>>
>> Yes, I mean "Evernote" in the next to the last paragraph--Evernote does
>> not have the same mulitenanted use case.
>>
>> I'm looking forward to your document, but I'm also at a conference this
>> week and want to have a few thoughts in mind for my presentation in case
>> anyone is interested.
>>
>> Marlon
>>
>> On 6/3/14 11:00 AM, Randy Heiland wrote:
>>> Marlon,
>>>
>>> In your last paragraph, you mean “Evernote...” and not “Thrift also has…” - correct?
>>>
>>> I believe you’re correct in your Thrift over HTTP for Evernote assumption, based on this:
>>> http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/201005.mbox/%3Ch2pc543765d1005031615t9b3e4a59ic77261d5b7bc08d3@mail.gmail.com%3E
>>>
>>> I actually have a doc to share with your team shortly regarding Evernote/Thrift that we did as part of our (CTSC) engagement with you. And I have some follow-on questions that I’ll contact you about offline.
>>>
>>> -Randy
>>>
>>> On Jun 3, 2014, at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>>
>>>> This email is intended to introduce some security discussion.
>>>>
>>>> One of the advantages of Thrift is the ability it will give us to
>>>> integrate native-language SDKs with desktop clients. This requires
>>>> though that we will need to think through our security model. In the
>>>> usual browser-based use case, the user does not make direct calls to the
>>>> API. These come instead from the gateway server, and we can establish a
>>>> trust relationship (such as SSL mutual authentication).
>>>>
>>>> For the desktop client case, users make direct calls to the Airavata API
>>>> server, so we have three actors: the desktop application, the API
>>>> Server, and an auth service. The Auth service performs initial
>>>> authentication of the user; it is a service that is gateway-dependent.
>>>> Without going into too many details, OAuth is the usual protocol for
>>>> doing this. Evernote, in their Thrift API, provides this as an option.
>>>>
>>>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>>>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>>>> does this mean we need to implement OAuth ourselves?
>>>>
>>>> Thrift also has a different use case in that they are not a
>>>> multi-tenanted service: they own all the accounts that they
>>>> authenticate. In contrast, a single Airavata server may support several
>>>> unrelated gateways. Each gateway would manage its own user accounts.
>>>>
>>>> What are the best options for Airavata?
>>>>
>>>>
>>>> Marlon
>>>>
>>
>
--
Samir Faci
*insert title*
fortune | cowsay -f /usr/share/cows/tux.cow
Sent from my non-iphone laptop.
Re: Thrift API security and desktop clients
Posted by Randy Heiland <he...@iu.edu>.
Fwiw, here’s the draft document I mentioned below:
http://pages.iu.edu/~heiland/ctsc/BestPracticesforThriftClients_EvernoteUseCase.pdf
I’d welcome any comments people might have.
-Randy
On Jun 3, 2014, at 9:05 AM, Marlon Pierce <ma...@iu.edu> wrote:
> Hi Randy--
>
> Yes, I mean "Evernote" in the next to the last paragraph--Evernote does
> not have the same mulitenanted use case.
>
> I'm looking forward to your document, but I'm also at a conference this
> week and want to have a few thoughts in mind for my presentation in case
> anyone is interested.
>
> Marlon
>
> On 6/3/14 11:00 AM, Randy Heiland wrote:
>> Marlon,
>>
>> In your last paragraph, you mean “Evernote...” and not “Thrift also has…” - correct?
>>
>> I believe you’re correct in your Thrift over HTTP for Evernote assumption, based on this:
>> http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/201005.mbox/%3Ch2pc543765d1005031615t9b3e4a59ic77261d5b7bc08d3@mail.gmail.com%3E
>>
>> I actually have a doc to share with your team shortly regarding Evernote/Thrift that we did as part of our (CTSC) engagement with you. And I have some follow-on questions that I’ll contact you about offline.
>>
>> -Randy
>>
>> On Jun 3, 2014, at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>>> This email is intended to introduce some security discussion.
>>>
>>> One of the advantages of Thrift is the ability it will give us to
>>> integrate native-language SDKs with desktop clients. This requires
>>> though that we will need to think through our security model. In the
>>> usual browser-based use case, the user does not make direct calls to the
>>> API. These come instead from the gateway server, and we can establish a
>>> trust relationship (such as SSL mutual authentication).
>>>
>>> For the desktop client case, users make direct calls to the Airavata API
>>> server, so we have three actors: the desktop application, the API
>>> Server, and an auth service. The Auth service performs initial
>>> authentication of the user; it is a service that is gateway-dependent.
>>> Without going into too many details, OAuth is the usual protocol for
>>> doing this. Evernote, in their Thrift API, provides this as an option.
>>>
>>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>>> does this mean we need to implement OAuth ourselves?
>>>
>>> Thrift also has a different use case in that they are not a
>>> multi-tenanted service: they own all the accounts that they
>>> authenticate. In contrast, a single Airavata server may support several
>>> unrelated gateways. Each gateway would manage its own user accounts.
>>>
>>> What are the best options for Airavata?
>>>
>>>
>>> Marlon
>>>
>
Re: Thrift API security and desktop clients
Posted by Marlon Pierce <ma...@iu.edu>.
Hi Randy--
Yes, I mean "Evernote" in the next to the last paragraph--Evernote does
not have the same mulitenanted use case.
I'm looking forward to your document, but I'm also at a conference this
week and want to have a few thoughts in mind for my presentation in case
anyone is interested.
Marlon
On 6/3/14 11:00 AM, Randy Heiland wrote:
> Marlon,
>
> In your last paragraph, you mean “Evernote...” and not “Thrift also has…” - correct?
>
> I believe you’re correct in your Thrift over HTTP for Evernote assumption, based on this:
> http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/201005.mbox/%3Ch2pc543765d1005031615t9b3e4a59ic77261d5b7bc08d3@mail.gmail.com%3E
>
> I actually have a doc to share with your team shortly regarding Evernote/Thrift that we did as part of our (CTSC) engagement with you. And I have some follow-on questions that I’ll contact you about offline.
>
> -Randy
>
> On Jun 3, 2014, at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>
>> This email is intended to introduce some security discussion.
>>
>> One of the advantages of Thrift is the ability it will give us to
>> integrate native-language SDKs with desktop clients. This requires
>> though that we will need to think through our security model. In the
>> usual browser-based use case, the user does not make direct calls to the
>> API. These come instead from the gateway server, and we can establish a
>> trust relationship (such as SSL mutual authentication).
>>
>> For the desktop client case, users make direct calls to the Airavata API
>> server, so we have three actors: the desktop application, the API
>> Server, and an auth service. The Auth service performs initial
>> authentication of the user; it is a service that is gateway-dependent.
>> Without going into too many details, OAuth is the usual protocol for
>> doing this. Evernote, in their Thrift API, provides this as an option.
>>
>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>> does this mean we need to implement OAuth ourselves?
>>
>> Thrift also has a different use case in that they are not a
>> multi-tenanted service: they own all the accounts that they
>> authenticate. In contrast, a single Airavata server may support several
>> unrelated gateways. Each gateway would manage its own user accounts.
>>
>> What are the best options for Airavata?
>>
>>
>> Marlon
>>
Re: Thrift API security and desktop clients
Posted by Randy Heiland <he...@iu.edu>.
Marlon,
In your last paragraph, you mean “Evernote...” and not “Thrift also has…” - correct?
I believe you’re correct in your Thrift over HTTP for Evernote assumption, based on this:
http://mail-archives.apache.org/mod_mbox/incubator-thrift-dev/201005.mbox/%3Ch2pc543765d1005031615t9b3e4a59ic77261d5b7bc08d3@mail.gmail.com%3E
I actually have a doc to share with your team shortly regarding Evernote/Thrift that we did as part of our (CTSC) engagement with you. And I have some follow-on questions that I’ll contact you about offline.
-Randy
On Jun 3, 2014, at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
> This email is intended to introduce some security discussion.
>
> One of the advantages of Thrift is the ability it will give us to
> integrate native-language SDKs with desktop clients. This requires
> though that we will need to think through our security model. In the
> usual browser-based use case, the user does not make direct calls to the
> API. These come instead from the gateway server, and we can establish a
> trust relationship (such as SSL mutual authentication).
>
> For the desktop client case, users make direct calls to the Airavata API
> server, so we have three actors: the desktop application, the API
> Server, and an auth service. The Auth service performs initial
> authentication of the user; it is a service that is gateway-dependent.
> Without going into too many details, OAuth is the usual protocol for
> doing this. Evernote, in their Thrift API, provides this as an option.
>
> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
> does this mean we need to implement OAuth ourselves?
>
> Thrift also has a different use case in that they are not a
> multi-tenanted service: they own all the accounts that they
> authenticate. In contrast, a single Airavata server may support several
> unrelated gateways. Each gateway would manage its own user accounts.
>
> What are the best options for Airavata?
>
>
> Marlon
>
Re: Thrift API security and desktop clients
Posted by Raminder Singh <ra...@gmail.com>.
User coming from the gateway portal server is easy to address using SSL mutual authentication.
For desktop clients, credential store can issue token for individual client and that can be use for authentication. We can restrict clients with valid token to create an airavata client. I am not sure if we can add something to Thrift server to validate token with credential store before creating a TCP channel. If it works, we need not to add token to every API function exposed by thrift client. If not we need to explore other options.
We still need to handle authorization for both the cases to restrict users to invoke experiments of other users.
Thanks
Raminder
On Jun 3, 2014, at 10:32 AM, Marlon Pierce <ma...@iu.edu> wrote:
> Thanks for the feedback, Amila.
>
> In case my original post wasn't too coherent, I'll restate it as a few
> questions.
>
> * For desktop clients (which a gateway may distribute), is some flavor
> of OAuth what we should do, or are there other choices?
>
> * If we are using OAuth + Thrift for the Airavata API server, should we
> look into running Thrift over HTTP and piggyback on some off-the-shelf
> OAuth (if such a thing exists), or should we implement OAuth within
> Thrift in some fashion. Note here Thrift does not have headers.
>
> * If we take Evernote as our example for desktop client OAuth, we have
> this problem: we can have 2 or more unrelated Gateways who both
> distribute unrelated desktop tools that may interact with the same
> Airavata hosted service. What variations on the Evernote model does this
> introduce?
>
> I'll omit OAuth 1 v OAuth 2.
>
> Marlon
>
>
>
> On 6/3/14 3:18 PM, Amila Jayasekara wrote:
>> Hi Marlon,
>>
>> Some quick thoughts after reading your description is as follows;
>>
>> 1. Each gateway need to authenticate with airavata server. i.e. unknown
>> gateway should not be able to communicate with airavata server. So the best
>> mechanism to achieve this (IMO) is SSL mutual authentication.
>> 2. Each gateway user needs to go through an authentication process and once
>> user is authenticated he/she should be tagged with the gateway id. Then
>> airavata server needs to have a session (or a context) in which
>> authenticated user is associated. All the operations must be performed
>> within the context. i.e. a gateway user should not be able to invoke any
>> operation out of the context. This restricts user executing operations on
>> behalf of another user in another gateway. Also any operation in the
>> airavata server should be permitted after user is authenticated. Basically
>> we are trying to achieve gateway isolation in multi-tenant scenario.
>>
>> Thanks
>> Amila
>>
>>
>> On Tue, Jun 3, 2014 at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>>> This email is intended to introduce some security discussion.
>>>
>>> One of the advantages of Thrift is the ability it will give us to
>>> integrate native-language SDKs with desktop clients. This requires
>>> though that we will need to think through our security model. In the
>>> usual browser-based use case, the user does not make direct calls to the
>>> API. These come instead from the gateway server, and we can establish a
>>> trust relationship (such as SSL mutual authentication).
>>>
>>> For the desktop client case, users make direct calls to the Airavata API
>>> server, so we have three actors: the desktop application, the API
>>> Server, and an auth service. The Auth service performs initial
>>> authentication of the user; it is a service that is gateway-dependent.
>>> Without going into too many details, OAuth is the usual protocol for
>>> doing this. Evernote, in their Thrift API, provides this as an option.
>>>
>>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>>> does this mean we need to implement OAuth ourselves?
>>>
>>> Thrift also has a different use case in that they are not a
>>> multi-tenanted service: they own all the accounts that they
>>> authenticate. In contrast, a single Airavata server may support several
>>> unrelated gateways. Each gateway would manage its own user accounts.
>>>
>>> What are the best options for Airavata?
>>>
>>>
>>> Marlon
>>>
>>>
>
Re: Thrift API security and desktop clients
Posted by Suresh Marru <sm...@apache.org>.
This is very nice discussion and I am eager to hear other experiences.
Are there any good OAuth implementations over TCP? One way to mitigate the missing header is to add a token filed and send it over TCP and the token can be validated on the server side just like we do extracting form header. Ofcourse this is not elegant but wonder if there are any security flaws in this approach?
Suresh
On Jun 3, 2014, at 10:32 AM, Marlon Pierce <ma...@iu.edu> wrote:
> Thanks for the feedback, Amila.
>
> In case my original post wasn't too coherent, I'll restate it as a few
> questions.
>
> * For desktop clients (which a gateway may distribute), is some flavor
> of OAuth what we should do, or are there other choices?
>
> * If we are using OAuth + Thrift for the Airavata API server, should we
> look into running Thrift over HTTP and piggyback on some off-the-shelf
> OAuth (if such a thing exists), or should we implement OAuth within
> Thrift in some fashion. Note here Thrift does not have headers.
>
> * If we take Evernote as our example for desktop client OAuth, we have
> this problem: we can have 2 or more unrelated Gateways who both
> distribute unrelated desktop tools that may interact with the same
> Airavata hosted service. What variations on the Evernote model does this
> introduce?
>
> I'll omit OAuth 1 v OAuth 2.
>
> Marlon
>
>
>
> On 6/3/14 3:18 PM, Amila Jayasekara wrote:
>> Hi Marlon,
>>
>> Some quick thoughts after reading your description is as follows;
>>
>> 1. Each gateway need to authenticate with airavata server. i.e. unknown
>> gateway should not be able to communicate with airavata server. So the best
>> mechanism to achieve this (IMO) is SSL mutual authentication.
>> 2. Each gateway user needs to go through an authentication process and once
>> user is authenticated he/she should be tagged with the gateway id. Then
>> airavata server needs to have a session (or a context) in which
>> authenticated user is associated. All the operations must be performed
>> within the context. i.e. a gateway user should not be able to invoke any
>> operation out of the context. This restricts user executing operations on
>> behalf of another user in another gateway. Also any operation in the
>> airavata server should be permitted after user is authenticated. Basically
>> we are trying to achieve gateway isolation in multi-tenant scenario.
>>
>> Thanks
>> Amila
>>
>>
>> On Tue, Jun 3, 2014 at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>>> This email is intended to introduce some security discussion.
>>>
>>> One of the advantages of Thrift is the ability it will give us to
>>> integrate native-language SDKs with desktop clients. This requires
>>> though that we will need to think through our security model. In the
>>> usual browser-based use case, the user does not make direct calls to the
>>> API. These come instead from the gateway server, and we can establish a
>>> trust relationship (such as SSL mutual authentication).
>>>
>>> For the desktop client case, users make direct calls to the Airavata API
>>> server, so we have three actors: the desktop application, the API
>>> Server, and an auth service. The Auth service performs initial
>>> authentication of the user; it is a service that is gateway-dependent.
>>> Without going into too many details, OAuth is the usual protocol for
>>> doing this. Evernote, in their Thrift API, provides this as an option.
>>>
>>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>>> does this mean we need to implement OAuth ourselves?
>>>
>>> Thrift also has a different use case in that they are not a
>>> multi-tenanted service: they own all the accounts that they
>>> authenticate. In contrast, a single Airavata server may support several
>>> unrelated gateways. Each gateway would manage its own user accounts.
>>>
>>> What are the best options for Airavata?
>>>
>>>
>>> Marlon
>>>
>>>
>
Re: Thrift API security and desktop clients
Posted by Marlon Pierce <ma...@iu.edu>.
Thanks for the feedback, Amila.
In case my original post wasn't too coherent, I'll restate it as a few
questions.
* For desktop clients (which a gateway may distribute), is some flavor
of OAuth what we should do, or are there other choices?
* If we are using OAuth + Thrift for the Airavata API server, should we
look into running Thrift over HTTP and piggyback on some off-the-shelf
OAuth (if such a thing exists), or should we implement OAuth within
Thrift in some fashion. Note here Thrift does not have headers.
* If we take Evernote as our example for desktop client OAuth, we have
this problem: we can have 2 or more unrelated Gateways who both
distribute unrelated desktop tools that may interact with the same
Airavata hosted service. What variations on the Evernote model does this
introduce?
I'll omit OAuth 1 v OAuth 2.
Marlon
On 6/3/14 3:18 PM, Amila Jayasekara wrote:
> Hi Marlon,
>
> Some quick thoughts after reading your description is as follows;
>
> 1. Each gateway need to authenticate with airavata server. i.e. unknown
> gateway should not be able to communicate with airavata server. So the best
> mechanism to achieve this (IMO) is SSL mutual authentication.
> 2. Each gateway user needs to go through an authentication process and once
> user is authenticated he/she should be tagged with the gateway id. Then
> airavata server needs to have a session (or a context) in which
> authenticated user is associated. All the operations must be performed
> within the context. i.e. a gateway user should not be able to invoke any
> operation out of the context. This restricts user executing operations on
> behalf of another user in another gateway. Also any operation in the
> airavata server should be permitted after user is authenticated. Basically
> we are trying to achieve gateway isolation in multi-tenant scenario.
>
> Thanks
> Amila
>
>
> On Tue, Jun 3, 2014 at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
>
>> This email is intended to introduce some security discussion.
>>
>> One of the advantages of Thrift is the ability it will give us to
>> integrate native-language SDKs with desktop clients. This requires
>> though that we will need to think through our security model. In the
>> usual browser-based use case, the user does not make direct calls to the
>> API. These come instead from the gateway server, and we can establish a
>> trust relationship (such as SSL mutual authentication).
>>
>> For the desktop client case, users make direct calls to the Airavata API
>> server, so we have three actors: the desktop application, the API
>> Server, and an auth service. The Auth service performs initial
>> authentication of the user; it is a service that is gateway-dependent.
>> Without going into too many details, OAuth is the usual protocol for
>> doing this. Evernote, in their Thrift API, provides this as an option.
>>
>> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
>> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
>> does this mean we need to implement OAuth ourselves?
>>
>> Thrift also has a different use case in that they are not a
>> multi-tenanted service: they own all the accounts that they
>> authenticate. In contrast, a single Airavata server may support several
>> unrelated gateways. Each gateway would manage its own user accounts.
>>
>> What are the best options for Airavata?
>>
>>
>> Marlon
>>
>>
Re: Thrift API security and desktop clients
Posted by Amila Jayasekara <th...@gmail.com>.
Hi Marlon,
Some quick thoughts after reading your description is as follows;
1. Each gateway need to authenticate with airavata server. i.e. unknown
gateway should not be able to communicate with airavata server. So the best
mechanism to achieve this (IMO) is SSL mutual authentication.
2. Each gateway user needs to go through an authentication process and once
user is authenticated he/she should be tagged with the gateway id. Then
airavata server needs to have a session (or a context) in which
authenticated user is associated. All the operations must be performed
within the context. i.e. a gateway user should not be able to invoke any
operation out of the context. This restricts user executing operations on
behalf of another user in another gateway. Also any operation in the
airavata server should be permitted after user is authenticated. Basically
we are trying to achieve gateway isolation in multi-tenant scenario.
Thanks
Amila
On Tue, Jun 3, 2014 at 2:33 AM, Marlon Pierce <ma...@iu.edu> wrote:
> This email is intended to introduce some security discussion.
>
> One of the advantages of Thrift is the ability it will give us to
> integrate native-language SDKs with desktop clients. This requires
> though that we will need to think through our security model. In the
> usual browser-based use case, the user does not make direct calls to the
> API. These come instead from the gateway server, and we can establish a
> trust relationship (such as SSL mutual authentication).
>
> For the desktop client case, users make direct calls to the Airavata API
> server, so we have three actors: the desktop application, the API
> Server, and an auth service. The Auth service performs initial
> authentication of the user; it is a service that is gateway-dependent.
> Without going into too many details, OAuth is the usual protocol for
> doing this. Evernote, in their Thrift API, provides this as an option.
>
> Evernote (from what I can tell) uses Thrift over HTTP, or at least uses
> an HTTP proxy. If we stay with TCP/IP Thrift services in Airavata,
> does this mean we need to implement OAuth ourselves?
>
> Thrift also has a different use case in that they are not a
> multi-tenanted service: they own all the accounts that they
> authenticate. In contrast, a single Airavata server may support several
> unrelated gateways. Each gateway would manage its own user accounts.
>
> What are the best options for Airavata?
>
>
> Marlon
>
>