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 Fri, 01 Aug 2014 17:21:31 GMT
Hi Marlon,

Basically there is no way to review the permissions of a particular role
from the user api side. But you can query on roles such as getAllRoleNames
which will return all the roles in the wso2 IS tenant excluding IS internal
roles such as admin.

To review the permissions related to roles you have to use the admin
console. Under
Home <https://idp.scigap.org:9443/t/phprg.scigap.org/carbon/admin/index.jsp>
 > Configure > Users and Roles
<https://idp.scigap.org:9443/t/phprg.scigap.org/carbon/userstore/index.jsp?region=region1&item=userstores_menu&ordinal=0>
 > Roles
<https://idp.scigap.org:9443/t/phprg.scigap.org/carbon/role/role-mgt.jsp?ordinal=1>
> Permissions
  -> Applications
you get the defined permissions for each application (api and the app
catalog). For each role you can change the set of permissions assigned from
this UI.

Currently I have added only some permission strings. But new permission
strings can be defined easily by navigating to
Home <https://idp.scigap.org:9443/t/phprg.scigap.org/carbon/admin/index.jsp>
 > Identity > Service Providers > List
<https://idp.scigap.org:9443/t/phprg.scigap.org/carbon/application/list-service-providers.jsp?region=region1&item=list_service_providers_menu&ordinal=0>
 >

After selecting a particular application under the Role/Permission
Configuration section you can define new permission strings.

The getUserPermissions in the user API returns APIPermissions object which
contains two maps. Each map contains set of permissions as keys and if the
user has that permission the value will be set to boolean true else false. When
querying the wso2 IS for user permissions it sends only the list of
permissions that the current user has. So to return a hash map of the above
described format the user api needs to know the entire set of user
permissions. So I add two configuration properties in the server.properties
file to list all the permission strings. The reason behind using maps is
that it enables faster verification of permissions provided that the gateway
or airavata server knows the corresponding permission string.
I have some concerns related to the above design decision. This assumes
that every tenant will have the same set of permission strings. This is
true in the context of API calls to the airavata server. But in case if we
want define gateway specific permission strings this solution is not
working. One solution is to add another list to hold such gateway specific
permission strings in the APIPermissions object


On Wed, Jul 30, 2014 at 7:00 PM, Marlon Pierce <marpierc@iu.edu> wrote:

> Hi Supun--
>
> How can I review the roles and permissions you've created using the IS
> admin console? Are these on the 7443 or 9443 server?
>
> Thanks--
>
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>
>


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

Mime
View raw message