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