I am not quite sure whether desktop client directly connect to SciGap (Multi-tenant Airavata). Cos the picture I am having in my mind for web cliensts is as follows;
[Browser] <-----------> [ Web/Application Server (Gateway Server) ] <-----------> [ SciGap ] So if I replace browser with desktop client I would get following; [Desktop Client] <-----------> [ Web/Application Server (Gateway Server)] <-----------> [ SciGap ] If desktop clients are allowed to directly connect to SciGap instance then they need to go through a certain registration (gateway) process. Also they have to bypass user mangement associated with the gateway. Further desktop clients gets privileged access than normal browser. Therefore to me it makes more sensible for desktop clients to connect to Gateway Server and not to SciGap. Thanks Amila On Mon, Feb 17, 2014 at 2:33 PM, Marlon Pierce <[email protected]> wrote: > The Airavata XBaya user composer tool will need to run this way. > > > Marlon > > On 2/17/14 2:26 PM, Borries Demeler wrote: > > Yes, we do. Raminder has been working with Emre Brookes on a desktop > implementation. > > I presume this capability will be integrated into the Thrift API. > > Raminder may be able to shed more light on the way authentication is > handled on the desktop. > > > > -b. > > > > On Mon, Feb 17, 2014 at 07:07:11PM +0000, Schwartz, Terri wrote: > >> Do we plan to support desktop clients with SciGap? I don't have any > particular suggestion to make regarding authentication mechanisms, just > want to understand what would be the burden on the end user of a scigap > enabled desktop application, with various authorization/authentication > choices. > >> > >> Terri > >> > >> ________________________________________ > >> From: Sachith Withana [[email protected]] > >> Sent: Monday, February 17, 2014 8:18 AM > >> To: [email protected]; [email protected] > >> Subject: Re: Securing the Thrift API > >> > >> The whole problem arises because we need to authenticate the client. > >> > >> In mutual authentication, you need to setup the server as well to > support > >> each and every client.( by adding certificates manually). But > scalability > >> can be an issue here? > >> > >> In terms of having a public API, Google, Evernote and Amazon web > services > >> uses OAuth 2.0 to authenticate the client. > >> And Evernote is using Thrift as well. > >> > >> I thought in terms of the SciGap perspective ( it can also support the > >> current use case scenarios). > >> > >> But as you mentioned, it can make things more complicated. ( Since > whoever > >> is using the thrift client would have to program to use the Oauth) > >> > >> For learning purposes : In terms of the operation, doesn't these two do > the > >> same thing? ( Oauth coupled with server public key authentication vs > mutual > >> authentication using certificates) ( apart from the fact that OAuth > >> supports delegation ?) > >> > >> User is delegating the thrift client to use the server right? > >> > >> > >> > >> > >> On Mon, Feb 17, 2014 at 11:01 AM, Amila Jayasekara > >> <[email protected]>wrote: > >> > >>> On Mon, Feb 17, 2014 at 10:36 AM, Sachith Withana <[email protected] > >>>> wrote: > >>>> Hi all, > >>>> > >>>> We are exploring the options on securing the Thrift API. > >>>> > >>>> Our objective is to authenticate the server and authorize the client. > >>>> > >>> What do you mean by authorizing client ? > >>> > >>>> The options we are exploring are > >>>> > >>>> 1. mutual authentication using client and server certificates > >>>> > >>> This seems to be a good fit according to my understanding. > >>> > >>> > >>>> 2. Use the server certificate to setup a SSL communication and use > OAuth > >>>> 1or 2 for the client Authorization > >>>> > >>> I dont see a requirement for doing this. Usually we use OAuth when we > need > >>> delegation. I am not clear how a delegation model fits here. Also it > make > >>> things complicated. > >>> > >>> Thanks > >>> Amila > >>> > >>> > >>>> Any suggestions on this matter are highly appreciated! > >>>> > >>>> -- > >>>> Thanks, > >>>> Sachith Withana > >>>> > >> > >> > >> -- > >> Thanks, > >> Sachith Withana > >
