You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Supun Nakandala <su...@gmail.com> on 2014/06/29 20:19:55 UTC
Notion of user roles in the PHP Reference Gateway
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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
In our ultimate solution, the gateway should not be the only gatekeeper
to the API. That is, if an API function is reserved for an admin, then
Airavata needs to independently check this. We need this to support
desktop clients, which are not centrally operated like web gateways.
The only way I see this is for the API to include a token, or perhaps a
token bag object. The gateway includes the user identity and token in
the call, and Airavata verifies the role of the user. The details are
left as a homework exercise for you.
Note this discussion may be better summarized on the Airavata
architecture list.
Marlon
On 7/1/14, 12:18 AM, Supun Nakandala wrote:
> As per my understanding this is bit tricky. We are considering three use
> cases
>
> 1. gateways which has a user store
> 2. gateways which has OAuth like authentication
> 3. gateways which does not have user store and wants to use proxy user
> API
>
> So if Airavata wants to check user roles, we need a consistent mechanism
> which is applicable in all three of these use cases. Also the set of roles
> should be universally defined across all gateways.
>
> I think the most convenient approach is to rely on the gateway to do the
> role verification and let the gateway delegate computations on behalf of
> it's users. This has it's limitations. What are your suggestions?
>
>
> On Tue, Jul 1, 2014 at 3:06 AM, Marlon Pierce <ma...@iu.edu> wrote:
>
>> Hi Supun, that sounds like the way the gateway interacts with the IS. But
>> Airavata also needs to check to see if the user has the correct role. What
>> is the best way to do that?
>>
>> Marlon
>>
>>
>> On 6/30/14, 4:00 PM, Supun Nakandala wrote:
>>
>>> The gateway admin can query the list of roles for a particular user given
>>> the username. Then the gateway admin can iterate through the list of roles
>>> and retrieve the capabilities to each role.
>>>
>>>
>>> On Tue, Jul 1, 2014 at 1:17 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>>
>>> A little question, maybe premature: how are these roles going to be
>>>> communicated over the Thrift-based API?
>>>>
>>>> Marlon
>>>>
>>>>
>>>>
>>>> On 6/30/14, 3:43 PM, Supun Nakandala wrote:
>>>>
>>>> Hi Suresh,
>>>>>
>>>>> On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <sm...@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
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
As per my understanding this is bit tricky. We are considering three use
cases
1. gateways which has a user store
2. gateways which has OAuth like authentication
3. gateways which does not have user store and wants to use proxy user
API
So if Airavata wants to check user roles, we need a consistent mechanism
which is applicable in all three of these use cases. Also the set of roles
should be universally defined across all gateways.
I think the most convenient approach is to rely on the gateway to do the
role verification and let the gateway delegate computations on behalf of
it's users. This has it's limitations. What are your suggestions?
On Tue, Jul 1, 2014 at 3:06 AM, Marlon Pierce <ma...@iu.edu> wrote:
> Hi Supun, that sounds like the way the gateway interacts with the IS. But
> Airavata also needs to check to see if the user has the correct role. What
> is the best way to do that?
>
> Marlon
>
>
> On 6/30/14, 4:00 PM, Supun Nakandala wrote:
>
>> The gateway admin can query the list of roles for a particular user given
>> the username. Then the gateway admin can iterate through the list of roles
>> and retrieve the capabilities to each role.
>>
>>
>> On Tue, Jul 1, 2014 at 1:17 AM, Marlon Pierce <ma...@iu.edu> wrote:
>>
>> A little question, maybe premature: how are these roles going to be
>>> communicated over the Thrift-based API?
>>>
>>> Marlon
>>>
>>>
>>>
>>> On 6/30/14, 3:43 PM, Supun Nakandala wrote:
>>>
>>> Hi Suresh,
>>>>
>>>>
>>>> On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <sm...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
Hi Supun, that sounds like the way the gateway interacts with the IS.
But Airavata also needs to check to see if the user has the correct
role. What is the best way to do that?
Marlon
On 6/30/14, 4:00 PM, Supun Nakandala wrote:
> The gateway admin can query the list of roles for a particular user given
> the username. Then the gateway admin can iterate through the list of roles
> and retrieve the capabilities to each role.
>
>
> On Tue, Jul 1, 2014 at 1:17 AM, Marlon Pierce <ma...@iu.edu> wrote:
>
>> A little question, maybe premature: how are these roles going to be
>> communicated over the Thrift-based API?
>>
>> Marlon
>>
>>
>>
>> On 6/30/14, 3:43 PM, Supun Nakandala wrote:
>>
>>> Hi Suresh,
>>>
>>>
>>> On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <sm...@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 <th...@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
>>>>>
>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
The gateway admin can query the list of roles for a particular user given
the username. Then the gateway admin can iterate through the list of roles
and retrieve the capabilities to each role.
On Tue, Jul 1, 2014 at 1:17 AM, Marlon Pierce <ma...@iu.edu> wrote:
> A little question, maybe premature: how are these roles going to be
> communicated over the Thrift-based API?
>
> Marlon
>
>
>
> On 6/30/14, 3:43 PM, Supun Nakandala wrote:
>
>> Hi Suresh,
>>
>>
>> On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <sm...@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 <th...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
Hi Supun--
I'm adding some review comments to code lines in github. Do you use your
startup scripts in ./userapi/src/main/resources/bin/? Unless there is a
big difference between my Mac's bash shell and your environment, these
don't work.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
Hi Supun--
A few additional notes on running the service.
* You should include notes in the README on how to start and stop the
service.
* It isn't clear where I should run the start_server.sh script. It
doesn't work in airavata-userapi/userapi/airvata-userapi (script can't
find setenv.sh), and it doesn't work in bin/ (the jar isn't in the
classpath).
* I'm not fond of the way the stop_server.sh script works.
* You misspelled "airavata" as "airvata" in your assembly.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
Hi Marlon,
Please see the inline comments
On Mon, Jul 28, 2014 at 7:07 PM, Marlon Pierce <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
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
directly.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
>>>>>>
>>>>>>
>>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <ma...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
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 <ma...@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 <ma...@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 <ma...@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 <ma...@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 <sm...@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
>>>>
>>>>
>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
Hi Marlon,
Please see the inline comments.
On Tue, Jul 8, 2014 at 8:12 PM, Marlon Pierce <ma...@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 <ma...@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 <ma...@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 <ma...@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 <sm...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
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?
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.
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 <su...@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 <ma...@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 <ma...@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 <ma...@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 <sm...@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
>>
>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
Hi Marlon,
Below is the schematic diagram of the proposed solution architecture.
​Supun.
On Tue, Jul 8, 2014 at 12:24 AM, Supun Nakandala <su...@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 <ma...@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 <ma...@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 <ma...@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 <sm...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
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 <ma...@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 <ma...@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 <ma...@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 <sm...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
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 <ma...@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 <ma...@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 <sm...@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
>>>>>>>
>>>>>>>
>>>>>>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
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 <ma...@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 <ma...@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 <sm...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
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 <ma...@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 <sm...@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 <th...@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
>>>>>
>>>>>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Amila Jayasekara <th...@gmail.com>.
On Mon, Jun 30, 2014 at 3:47 PM, Marlon Pierce <ma...@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 <sm...@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 <th...@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
>>>>
>>>>
>>>
>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Marlon Pierce <ma...@iu.edu>.
A little question, maybe premature: how are these roles going to be
communicated over the Thrift-based API?
Marlon
On 6/30/14, 3:43 PM, Supun Nakandala wrote:
> Hi Suresh,
>
>
> On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <sm...@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 <th...@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
>>>
>>
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
Hi Suresh,
On Mon, Jun 30, 2014 at 5:57 PM, Suresh Marru <sm...@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 <th...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Suresh Marru <sm...@apache.org>.
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
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 <th...@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 <su...@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
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Amila Jayasekara <th...@gmail.com>.
Hi Supun,
You can try XACML. But XACML is for fine grained authorisation. But in
gateways we expect there will be well defined roles and well defined
authorization points. Therefore, IMO, we don't need XACML authorisation.
(At least for now).
Thanks
-Thejaka Amila
On Mon, Jun 30, 2014 at 3:29 PM, Supun Nakandala <su...@gmail.com>
wrote:
> Hi Amila,
>
> With a quick research on the functionality of WSO2 IS, I found that with
> XACML based entitlement management and roles the expected behavior is
> attainable. I am looking into this in more detail now.
>
> Thank you
>
>
> On Mon, Jun 30, 2014 at 1:23 PM, 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
>
Re: Notion of user roles in the PHP Reference Gateway
Posted by Supun Nakandala <su...@gmail.com>.
Hi Amila,
With a quick research on the functionality of WSO2 IS, I found that with
XACML based entitlement management and roles the expected behavior is
attainable. I am looking into this in more detail now.
Thank you
On Mon, Jun 30, 2014 at 1:23 PM, Amila Jayasekara <th...@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
Re: Notion of user roles in the PHP Reference Gateway
Posted by Amila Jayasekara <th...@gmail.com>.
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 <su...@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
>