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