airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amila Jayasekara <thejaka.am...@gmail.com>
Subject Re: Notion of user roles in the PHP Reference Gateway
Date Tue, 01 Jul 2014 14:35:38 GMT
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