airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <>
Subject Re: Notion of user roles in the PHP Reference Gateway
Date Mon, 28 Jul 2014 13:37:53 GMT
Hi Supun--

Nice progress and writeup. I'll test out with the php client samples. 
Some small comments below.

* Does the "authenticateGateway()" method authenticate a user to a 
particular gateway, or do I misunderstand?

* You should add a "disableUser()" method. Hopefully this is easily 
implemented in the IS. A disabled user may be able to authenticate but 
not be able to do anything (no permissions), or he/she may simply be 
denied authentication. But all the user's profile information and roles 
are retained in case the account is re-enabled.

* Are you assigning permissions directly to the user object or 
indirectly through roles. That is, the role has the permission and the 
user is assigned to the role. The API implies it is assigned to the user 
directly but it seems like a better design to assign these to the roles 


On 7/25/14, 1:35 PM, Supun Nakandala wrote:
> Hi All,
> During the past few weeks I have done several changes to the airavata user
> api. The new thrift interface descriptors can be found at
> Most of the new changes are related to permissions and role.
>     - Earlier it was possible to create roles and delete them from the user
>     api side. But now I have removed that. Now roles can be created and deleted
>     only from the WSO2 IS management console.
>     - I have added addUserToRole <to add a user to role/group>,
>     removeUserFromRole <to remove user from role>, getUserListOfRole <to get
>     the user list of particular role>, getRoleListOfUser <to get the role
>     list for a user. user can have more than one role>, getAllRoleNames
>     <this return the gateway specific roles list. i.e except IS roles like
>     admin, and Internal/*>
>     - As per the gateway specific roles I have created the roles from the
>     WSO2 IS side specified by Suresh previously in this thread.
>     - In terms of permission validation I have added getUserPermissions and
>     checkPermission methods.
>     - getUserPermissions returns an object (
>     which contains two maps of permissions sets one for airavata api and other
>     for app catalog. The key value in these maps is the name of the api method
>     and the value will be true if the user has permission else false. In
>     addition to these to maps it also has a string signature. I have added this
>     signature so that this object can be verified by the server or any intended
>     party. This addresses the issue of avoiding too many calls to server as
>     Marlon mentioned previously in this thread. Currently this signature is
>     prepared by concatenating the serialized strings of the two maps and the
>     time stamp which is then encrypted using AES.
>     - checkPermission method can verify whether a user has a particular
>     permission. eg
>     getUserPermission('scnakandala','airavata-api/create_project',$token)
>     - Also now the authenticateUser method returns the same output as in
>     getUserPermissions if the authentication is successful.
> I also looked into the concerns related to token generation.
> Although wso2 IS provides OAuth based authentication/authorization there is
> a problem of using it in the user api. User api is operated by calling the
> admin services of the wso2 IS under the cover. These services are soap
> endpoints and cannot be accessed via oauth authorization. There are SCIM
> REST services which can be accessed via oauth authorization but those
> services are not sufficient for the user api functions.
> Currently I have used http basic authentication. This means for every soap
> call from user api to wso2 IS I send admin username and the password of the
> tenant in use. Since we are sending the username IS knows on which tenant
> we are dealing with. This creates two possibilities for the communication
> between gateway and the user api
>     1. gateway send tenant admin username and password with every request to
>     the user api
>     2. user api stores tenant admin's username and password upon successful
>     gateway authentication and issue a temporary token to identify the gateway.
>     This requires to maintain tokens, username, password information at the
>     user api.
> In the current implementation I have followed the second approach with a
> slight change. Rather than storing the credential information I have embed
> the credential information and time stamp in the token. This token is then
> encrypted using AES. So when a gateway calls a method with the token user
> api can decrypt the token and retrieve the gateway admin credentials. This
> was done for easy implementation. But if sending username, password
> information has security implications we can implement a token store in the
> user api side to store the gateway admin's credential information.
> I renamed the previous adminLogin method to authenticateGateway to better
> suit its purpose. Upon successful authentication it returns a
> AuthenticationResponse (
> which contains the token and the time to expire.
> At the gateway side the gateway has to call this method at an interval
> which corresponds to the expiration time of the token. For the PHP
> Reference Gateway I have added this feature where it stores the token
> information in a xml file. (
> Though for every user api call the token has to be read from this file it
> will not be an issue as this file will get buffed in the memory most of the
> time.
> I have incorporated these changes to the PHP Reference Gateway and also
> updated the php client sample which can be found at
> Thank you
> Supun
> On Thu, Jul 10, 2014 at 4:10 PM, Marlon Pierce <> wrote:
>> Thanks, Supun. Some comments and questions below:
>> * When and how often does the adminLogin method get invoked?
>> * The string that adminLogin returns is the encrypted token you describe
>> below?
>> * I don't like the idea of sending around tokens with embedded passwords,
>> even if encrypted. Why do you require this? I think you need to rethink
>> this part and look more closely at other multi-party Web security protocols
>> (OAuth, OpenID,...).
>> * How are you encrypting? Amila pointed out earlier that public key
>> encryption is slow and usually shared secret keys are used after some
>> handshake.
>> * Also you need to take into account that these calls to the IS are
>> frequent operations in your design. They can't add a lot of overhead to the
>> process (too much network communication, too much time
>> encrypting/decrypting, server gets overloaded processing requests, etc).
>> * You need to think about scaling. Servers are not up all the time, can't
>> handle infinite requests in zero time, and don't have infinitely fast and
>> wide network connections. If we have lots of over the wire communications
>> to the IS for every single Airavata API requests, this won't scale.
>> * For permission checking, I think your second approach is better. There
>> is no need for Airavata to do the checking itself. It should just ask the
>> IS if OK and bet a yes/no answer. You could also expose "getRoles" and
>> "getPermissions" as optional methods.
>> Marlon
>> On 7/9/14, 7:58 AM, Supun Nakandala wrote:
>>> Hi Marlon,
>>> Please see the inline comments.
>>> On Tue, Jul 8, 2014 at 8:12 PM, Marlon Pierce <> 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 and password to the user api and get
>>>      authenticated. This operation corresponds to (
>>> 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 <
>>>>> 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.
>>>>>> 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
>>>>>> 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 <>
>>>>>> wrote:
>>>>>>    That's great.  Can you say more about your plans?  Two concerns:
>>>>>>> * The new application catalog functions fit within the "gateway
>>>>>>> role that Suresh listed previously.
>>>>>>> * The API also does not distinguish which gateway may be calling
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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 <>
>>>>>>>> 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 <>
>>>>>>>>>   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
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>>>> 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
>>>>>>>>>>>>> -
>>>>>>>>>>>>>      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
>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>>>       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
>>>>>>>>>>>>>      I would like to know what type of
role based functionality
>>>>>>>>>>>>> is
>>>>>>>>>>>>> required
>>>>>>>>>>>>>       in the context of the PHP Reference
>>>>>>>>>>>>>>       Thank you.
>>>>>>>>>>>>>    Supun
>>>>>>>>>>>>>>   --
>>>>>> Thank you
>>>>>> Supun Nakandala
>>>>>> Dept. Computer Science and Engineering
>>>>>> University of Moratuwa

View raw message