Let me see if I can clarify: Airavata expects clients (or gateways) to manage users and groups. And Airavata relies on gateway portal request (which it will blindly trust-based on well secure communications) to tell which user and group is making a request. The discussion I see now happening is for Airavata to manage the input and output data. So it will need its own internal structure on how to manage these.
If a gateway choose to, it can leverage this structure, but this will not be required. As for the data model: I suggest against making any implicit derivations of the data models these leads to ambiguity once the motivation is forgotten. I rather suggest making explicit changes to the data model if the need is justified. Airavata data model as I understand is as follows: Gateways-> Users-> Projects->Experiments I think what we are talking is to change it induce a groups in between which is a fine addition, so then it should be: Gateways-> Groups-> Users-> Projects-> Experiments. Simpler use cases may choose to always use a single default group and a user may choose to have single project. In that case, it shows like: Gateways->Users->Experiments, but in the backend its always should have a self-explanatory hierarchy. Suresh On Jan 31, 2014, at 2:49 PM, Miller, Mark <[email protected]> wrote: > I think we agreed that the Gateways would be responsible for user management, > but maybe that is at a different level? > > From: Sachith Withana [mailto:[email protected]] > Sent: Friday, January 31, 2014 11:46 AM > To: [email protected] > Subject: Re: Users and UserGroups in Science Gateways > > Thanks Raman, > I looked into the tables. It looks to be a viable option. > But is it okay to manage the users from the Airavata server itself? > > > On Fri, Jan 31, 2014 at 1:03 PM, Raminder Singh <[email protected]> > wrote: > Looking at Airavata Data model, there is project which is equivalent to User > group. A project can have multiple user for a gateway and a gateway can have > multiple projects. > > Thanks > Raminder > > On Jan 31, 2014, at 12:44 PM, Saminda Wijeratne <[email protected]> wrote: > > > > > > On Fri, Jan 31, 2014 at 9:28 AM, Miller, Mark <[email protected]> wrote: > As an end user, I think even with just a single tool, the argument for a > group is there. > As Saminda suggested, one may wish to have a join area to work in with a > group, and individual work you aren’t ready to share, even with just a single > tool. > > Because a Gateway is wide open, it is easy to imagine a case where there are > several groups, each with (potentially overlapping) users, who all are > working with Amber for different projects.. > Agreed. I totally forgot about shared projects scenario. Thanks for pointing > it out Mark. > > Mark > > From: Saminda Wijeratne [mailto:[email protected]] > Sent: Friday, January 31, 2014 9:11 AM > To: dev > Subject: Re: Users and UserGroups in Science Gateways > > I'm not an expert on the Amber usecase, but I suppose it is possible to have > multiple user groups for a single usecase. It could be to have a shared space > of data hidden from each user group. It could be to author > access/privilledges to the portal or resources depending on the user group. > > I would assume the mapping of user to usergroups would be many to one > mapping. Unlike user roles I don't think it is sensible to have users being > mapped to multiple groups (there is a whole area of security to consider > here). > > (I do have to note that usergroup IMO is not a must concept for a science > gateway) > > > On Fri, Jan 31, 2014 at 8:55 AM, Sachith Withana <[email protected]> wrote: > Hi all, > > Can someone explain to me the mapping of users to groups in a Science > Gateway? ( This is regarding the Amber usecase). > > Can there be multiple user groups in a gateway portal when it comes to just > one usecase? > ex: If we have only one usecase for the portal ( such as Amber) > > -- > Thanks, > Sachith Withana > > > > > > > > -- > Thanks, > Sachith Withana >
