airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Notion of user roles in the PHP Reference Gateway
Date Mon, 07 Jul 2014 17:59:22 GMT
Hi Supun, what do you think of Amila's suggestion below?

Marlon

On 7/1/14, 10:35 AM, Amila Jayasekara wrote:
> On Mon, Jun 30, 2014 at 3:47 PM, Marlon Pierce <marpierc@iu.edu> wrote:
>
>> A little question, maybe premature: how are these roles going to be
>> communicated over the Thrift-based API?
>
> This is what I have in mind;
>
> Each API function has a permission string (E.g :- for executeExperiment()
> permission string is "/apache/airavata/execute"). These permission strings
> are defined in IS. Also IS is connected to user store (LDAP or Database) in
> read/write mode. But Airavata should be connected to user store in "read
> only" mode.
>
> There are 2 steps to consider.
>
> Step 1 : Granting permission - For this we expect an administrator (maybe
> tenant admin) to follow below steps;
> 1. Login to IS as administrator
> 2. Select/Create role
> 3. Assign appropriate permissions to role
> 4. Add needed users to role
>
> Step 2 : Authorising user at Airavata
> 1. Before invoking API function we authenticate user. From this we get user
> name
> 2. Then we need to check whether user is authorized to execute function.
> 3. For this we need to get the permission (permission string) associated
> with currently executing function. (We need to figure out where these
> permission to function mapping should be stored)
> 4. Now invoke "IS user API" to check whether user has permissions
> (isUserAuthorise(permission, username) kind of function in "IS API")
> 5. "IS API" will take care of finding appropriate roles and permissions and
> will finally return whether user is authorized or not for given permission
> string
> 6. Based on the return value you continue operation or throw an error.
>
> So if I go to your original question (i.e. how roles are communicated over
> thrift ?); the answer is we do not communicate role to Airavata. We only
> send user name/password (or some other authentication data) to Airavata.
> But Airavata needs to communicate with underlying user store in read only
> mode. For this we can use IS user store API. From the user name the "User
> store API" will figure out roles and also associated permissions.
>
> All above are based on my knowledge I had 2 years ago about IS. Things
> might have changed. So Supun, please check how to achieve above
> functionality with current IS.
>
> Thank you
> Regards
> -Thejaka Amila
>
>
>>
>> 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
>>>>>
>>>>>


Mime
View raw message