airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <>
Subject Re: Gateway id in airavata request
Date Wed, 28 Nov 2012 14:29:02 GMT
Hi All,

After having a chat on last Monday we came to following conclusions.

We will have a default gateway - This is going to be the bootstrap
gateway. If users want to just try out Airavata without managing their
user store, they can use the default gateway. The default gateway will
come with an internal user store.
If clients need to manage their own users, they have to first register
themselves with the hosted Airavata service.
During registration they will share a common secret. Airavata will use
this common secret for authentication. User level
authentication and authorization must be implemented at portal level.
We also assume that there will be a portal for each gateway.

We also wanted to send the gateway id with the request. The approach
we are thinking is to have the gateway id as a separate
field in the request. This field will be a http header and its name is
"gateway". The client has to
populate this field in the request. If the request does not contain a
gateway id, we will direct the request
to default gateway. Further we will have DNS like format for the
gateway id. But for the default gateway we will use
string "default".

After introducing above change all server components must get the user
name and gateway from the context.
There shouldn't be any API methods with arguments username or gateway
name. We are yet to introduce gateway id to
the request context (I will do it today). But you can get the
authenticated user name from
We will have a similar method to get the gateway id.
This will only work if the calling code is in the same thread as the
request. In a spawned thread you will not be able to call context

Sorry about the delay in sending notes.

Appreciate your feedback.


On Sat, Nov 24, 2012 at 5:22 PM, Suresh Marru <> wrote:
> Hi Lahiru,
> I agree that jumping into supporting multi-tenant without too much thought is bad idea.
But I think Amila's questions are still very relevant. May be security is the time where we
should start thinking about how we separate the data if two instances share registry. Lets
say we have one workflow repository for all published workflows, if we want to have a development
workflows also to be published and tried, may be we can do that by simply creating a new development
registry space.
> Just a thought,
> Suresh
> On Nov 24, 2012, at 4:52 PM, Lahiru Gunathilake <> wrote:
>> Hi Amila,
>> I think right now we support only a single gateway and its configured
>> during start up time. I think we don't have proper multi-tenant data model
>> and I think its not a good time to provide users to register different
>> gateways.
>> Unless we have a well defined multi-tenant data model we shouldn't add
>> api methods to register gateways. But we can add methods to get the gateway
>> ID of a particular instance.
>> I think we are trying to think about multi-tenancy here which we haven't
>> discussed properly.
>> Lahiru
>> On Fri, Nov 23, 2012 at 11:55 AM, Amila Jayasekara
>> <>wrote:
>>> introduce
>> --
>> System Analyst Programmer
>> PTI Lab
>> Indiana University

View raw message