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 18:21:06 GMT
That's great.  Can you say more about your plans?  Two concerns:

* The new application catalog functions fit within the "gateway admin" 
role that Suresh listed previously.

* The API also does not distinguish which gateway may be calling the 
server. This is the multi-tenanted scenario--that is, multiple gateways 
call the same Airavata server.

So I strongly advise making a sample plan based on simple scenarios and 
share this on the dev list as soon as possible so that we make sure you 
are on the right path.

Marlon

On 7/7/14, 2:10 PM, Supun Nakandala wrote:
> I do agree with Amila. XACML can be used to implement very fine grained
> authorization. But that level is not required in the Airavata context.
>
>  From WSO2 IS 5.0 on wards we can register applications with IS and define
> various permissions and grant these permissions to users. This is exactly
> inline with what Amila suggested previously. I am planning to use this
> feature to implement authorization of the Airavata API.
>
>
> On Mon, Jul 7, 2014 at 11:29 PM, Marlon Pierce <marpierc@iu.edu> wrote:
>
>> 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