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 own 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 org.apache.airavata.common.context.WorkflowContext.getRequestUser(). 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 methods. Sorry about the delay in sending notes. Appreciate your feedback. Thanks Amila On Sat, Nov 24, 2012 at 5:22 PM, Suresh Marru <[email protected]> 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 <[email protected]> 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 >> <[email protected]>wrote: >> >>> introduce >> >> >> >> >> -- >> System Analyst Programmer >> PTI Lab >> Indiana University >
