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 <marpi...@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 <marpi...@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 <sma...@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.am...@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.nakand...@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
