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 Mon, 28 Jul 2014 13:48:58 GMT
Hi Marlon,

Please see the inline comments


On Mon, Jul 28, 2014 at 7:07 PM, Marlon Pierce <marpierc@iu.edu> wrote:

> 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?
>
 authenticateGateway method is called for authenticating the gateway. Not
for authenticating a particular user. For authenticating a user
authenticateUser
method has to be used.


>
> * 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.
>
I did some research into this previously. But apparently  there is no
explicit way of disabling a user. What they have suggested is to specify a
new role for disabled users and assign it. I'll see more into this. [
http://stackoverflow.com/questions/15420138/wso2-identity-server-deactivating-user-account
]

>
> * 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 directly.
>
The permissions are added to roles. This has to be configured from the wso2
IS side. Not from the User API. From the user api gateways can assign roles
to users and remove them via the methods addUserToRole and
removeUserFromRole.

>
>
> Marlon
>
>
>
>
> 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
>> https://github.com/scnakandala/airavata-userapi/
>> tree/master/userapi/thrift-interface-descriptors
>>
>> 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 (
>>
>>     https://github.com/scnakandala/airavata-userapi/
>> blob/master/userapi/thrift-interface-descriptors/userAPIModels.thrift#L50
>> )
>>     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 (
>> https://github.com/scnakandala/airavata-userapi/
>> blob/master/userapi/thrift-interface-descriptors/userAPIModels.thrift#L45
>> )
>> 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. (
>> https://github.com/SciGaP/PHP-Reference-Gateway/blob/master/
>> userapi_tokens.xml).
>> 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
>> https://github.com/scnakandala/airavata-userapi/tree/master/clients/php-
>> client/client-samples
>>
>> Thank you
>> Supun
>>
>>
>> On Thu, Jul 10, 2014 at 4:10 PM, Marlon Pierce <marpierc@iu.edu> 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 <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