Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <53B1D877.6080102@iu.edu>
Date: Mon, 30 Jun 2014 17:36:55 -0400
From: Marlon Pierce <marpierc@iu.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: dev@airavata.apache.org
Subject: Re: Notion of user roles in the PHP Reference Gateway
References: 
 <CAFwzmVAw0GiD0hWMj3sHg5d1Kw1c7S5U9SN6F9NV-yR6ZpHuag@mail.gmail.com>
	<CAKUcLKbbApj+oxSzzKC0ysOnLKPKOUN3CmamuF_J5YAP3B7_Dw@mail.gmail.com>
	<83A6DF07-2C0D-4970-95B0-C264555BF531@apache.org>
	<CAFwzmVANg-4xY9BBSLUtXUWieAYZ=CXB_DUASB3MJhjVEx85NQ@mail.gmail.com>
	<53B1BEE0.3020008@iu.edu>
 <CAFwzmVCEnxJr=Y1RB-R_EeqYZLunGBdrq3vL_mjFPyAx293K1g@mail.gmail.com>
In-Reply-To: 
 <CAFwzmVCEnxJr=Y1RB-R_EeqYZLunGBdrq3vL_mjFPyAx293K1g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Supun, that sounds like the way the gateway interacts with the IS.  
But Airavata also needs to check to see if the user has the correct 
role.  What is the best way to do that?

Marlon

On 6/30/14, 4:00 PM, Supun Nakandala wrote:
> The gateway admin can query the list of roles for a particular user given
> the username. Then the gateway admin can iterate through the list of roles
> and retrieve the capabilities to each role.
>
>
> On Tue, Jul 1, 2014 at 1:17 AM, Marlon Pierce <marpierc@iu.edu> wrote:
>
>> A little question, maybe premature: how are these roles going to be
>> communicated over the Thrift-based API?
>>
>> Marlon
>>
>>
>>
>> On 6/30/14, 3:43 PM, Supun Nakandala wrote:
>>
>>> Hi Suresh,
>>>
>>>
>>> On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <smarru@apache.org> wrote:
>>>
>>>   Hi Supun,
>>>> Amila is right on. To your question on what roles PHP Gateway will need,
>>>> I
>>>> will make a first order approximation and suggest the following:
>>>>
>>>> Casual Users - When users stumble upon a gateway, provide basic
>>>> tutorials.
>>>> For example, we used to allow casual users execute educational
>>>> experiments
>>>> - http://www.atmos.millersville.edu/~lead/modules.htm
>>>>
>>> I think in Casual Users the requirement is to have experiment level access
>>> control and not API level access controlling. So I think in addition to
>>> considering the API level functions as resources (as Amila suggested) we
>>> may have to define several other resources which does not have a direct
>>> mapping to API level functions but will require in order to handle this
>>> type of scenarios.
>>>
>>>
>>>   Gateway Users - These users are vetted by the administrators and pretty
>>>> much have permission to execute all applications and charge to
>>>> allocations.
>>>>
>>>> Application Providers - This role will allow to register new applications
>>>> and workflows (as opposed to only using them by gateway users).
>>>>
>>>> Gateway Administrators - essentially tenant admins. Manage community
>>>> account credentials, add remove user roles and other admin functions.
>>>>
>>>> Gateway Operators - Typically this is done by gateway administrators
>>>> themselves, but better to have a separate role. These role will be used
>>>> for
>>>> notifying when user experiments go wrong due to infrastructure reasons.
>>>> Enable/Disable compute resources, applications.
>>>>
>>>> A users may be in one or more roles.
>>>>
>>>> Suresh
>>>>
>>>>
>>>> On Jun 30, 2014, at 3:53 AM, Amila Jayasekara <thejaka.amila@gmail.com>
>>>> wrote:
>>>>
>>>>   Hi Supun,
>>>>> I would expect following; (others please correct me if I am wrong)
>>>>>
>>>>> We need to control access to API functions through roles. Also IS has a
>>>>>
>>>> notion of permissions and resources. So the resources are mapped to
>>>> functions defined in thrift API. So a permission would look like follows
>>>> (hypothetically);
>>>>
>>>>> permission = ("execute", /scigap/thrift/executeExperiment);
>>>>>
>>>>> We should be able to attach such permissions to roles. So when user
>>>>>
>>>> invokes an API function we need to do following;
>>>>
>>>>> 1. find user's role
>>>>> 2. examine role's permissions
>>>>> 3. check whether any role has permission relevant to invoking function
>>>>>
>>>>> AFAIK IS provided a way to define permissions and attach them to roles.
>>>>>
>>>> You may need to check how those can be used through APIs and how achieve
>>>> above described functionality.
>>>>
>>>>> Thanks
>>>>> Regards
>>>>> -Thejaka Amila
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jun 29, 2014 at 2:19 PM, Supun Nakandala <
>>>>>
>>>> supun.nakandala@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I am in the process of incorporating the notion of roles to the PHP
>>>>>
>>>> Reference Gateway using the proxy user api that I am developing. WSO2 IS
>>>> enables the tenant admin (gateway admin) to create roles and assign users
>>>> to roles (many to many mapping). From the gateway side we can consume
>>>> these
>>>> services and implement role based user functionality. The roles defined
>>>> will only be visible to that particular gateway(tenant).
>>>>
>>>>> I would like to know what type of role based functionality is required
>>>>>
>>>> in the context of the PHP Reference Gateway.
>>>>
>>>>> Thank you.
>>>>> Supun
>>>>>
>>>>>
>