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 <[email protected]> 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 <[email protected]> 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 >>> >>> >
