airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Nakandala <supun.nakand...@gmail.com>
Subject Re: Notion of user roles in the PHP Reference Gateway
Date Wed, 09 Jul 2014 11:58:08 GMT
Hi Marlon,

Please see the inline comments.


On Tue, Jul 8, 2014 at 8:12 PM, Marlon Pierce <marpierc@iu.edu> wrote:

> 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?
>
> The flow goes like this.

   1. First the tenant admin should provide his username (username@domain,
   eg admin@phprg.scigap.org) and password to the user api and get
   authenticated. This operation corresponds to (
   https://github.com/scnakandala/airavata-userapi/blob/master/userapi/thrift-interface-descriptors/userAPI.thrift#L65)
   method in thrift interface descriptor. If the  login is successful user api
   creates an encrypted token which contains the username of the admin (with
   the domain) , password and the time stamp. For all other api methods the
   gateway should send this token. The valid time duration of this token is
   configurable.
   2. When checking for permissions I am going to use an API method as *bool
   isUserAuthorized(username, permissionString, token) . *As this request
   contains the token we can decrypt it find the gateway admin's username,
   domain, and password and use these credentials to the communication between
   wso2 IS and user api. *From the domain we can distinguish which gateway
   the user is associated with*.

For checking the permissions of the gateway user and gateway admin user (or
any other roles) there are two approaches.

   - given a username and the permission string first fetch the roles of
   that user and then retrieve the permissions of those roles to check the
   permissions.
   - given a username and the permission string use the wso2 IS directly to
   check the permissions.

I personally prefer the second approach. In this approach we can define
permission strings and assign these permissions to different roles. [If you
can login to the wso2 IS phprg tenant you can see the permissions that I
have defined and the roles that I have created.] If we want to check
permission for a user from the user API side we need not to bother about
the roles of that particular user. We can simply send the username and
permission string to the wso2 IS which will check whether this user has at
least one role which contains the given permission.

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.

I understand the requirement. I'll see to this also

> 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
>>>
>>>
>>
>>
>


-- 
Thank you
Supun Nakandala
Dept. Computer Science and Engineering
University of Moratuwa

Mime
View raw message