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 Tue, 08 Jul 2014 14:42:31 GMT
Thanks, Supun. Could you say more about the UserAPI at the top?

Please also say more about the implementation. For example, how do you 
check permissions for the "gateway user" role and the "gateway admin" 
role? Also, how can Airavata determine which gateway the user is 
associated with?

Later, it may be nice if there was some way to avoid the call from 
Airavata to the UserAPI (step 3). For example (just brainstorming), when 
the user logs, the UserAPI returns a session object that has all the 
user's roles and permissions. This object includes signing information 
from the IS that Airavata can verify directly. This would remove the 
call (step 3) and so may increase reliability. Performance may or may 
not increase, depending on how long it takes to verify the signature.

Marlon

On 7/8/14, 1:00 AM, Supun Nakandala wrote:
> Hi Marlon,
>
> Below is the schematic diagram of the proposed solution architecture.
>
> ​Supun.
>
>
> On Tue, Jul 8, 2014 at 12:24 AM, Supun Nakandala <supun.nakandala@gmail.com>
> wrote:
>
>> My plan is to use tokens when calling the API methods. These tokens will
>> be granted by the user store at the time of user authentication. This
>> tokens will be encrypted tokens which will contain the information about
>> the gateway which can be used to verify the identity of the gateway.
>> When authorization happens the user store has to call the correct WSO2 IS
>> tenant. It can use the information inside the token to do so.
>>
>> I will give a schematic diagram of the proposed solution ASAP.
>>
>>
>> On Mon, Jul 7, 2014 at 11:51 PM, Marlon Pierce <marpierc@iu.edu> wrote:
>>
>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
>> --
>> Thank you
>> Supun Nakandala
>> Dept. Computer Science and Engineering
>> University of Moratuwa
>>
>
>


Mime
View raw message