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 Wed, 30 Jul 2014 15:56:48 GMT
Hi Supun--

I got things working, more or less. I had to "localize" the startup 
scripts to get the API server to start; see my comments in github. The 
PHP command line tools work fine, but I was not able to run the unit 
tests (see attachment).

The core work looks good but you have several rough edges still. I may 
have deeper comments about the core later.

Marlon

On 7/28/14, 9:48 AM, Supun Nakandala wrote:
> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>


Mime
View raw message