airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hasini Gunasinghe (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-1624) [GSoC] Securing Airavata API
Date Thu, 04 Jun 2015 02:03:38 GMT


Hasini Gunasinghe commented on AIRAVATA-1624:

Hi Supun,

Thanks for the comments. 
Concerning multi-tenancy, yes, I have considered it when designing the solution (please refer
the 6th comment on this jira). Once the architectural details of multi-tenanted Airavata is
finalized (i.e: how a tenant will be identified, how the configuration files will be cloned
and stored for each tenant etc), current security manager can be easily extended to support
multi-tenancy accordingly. AuthzToken already contains a properties map for passing user attributes
which can be used to pass the tenant identifier or we can introduce a separate field based
on the tenant identifier that will be used in Airavata.

Concerning the TLS support, thanks for informing that thrift doesn't support TLS for PHP client.
I was anyway planning to make the communication over TLS configurable, so that any one who
prefers performance over security can use the communication without TLS. For that, we will
have two endpoints: one exposed over TLS and the other one exposed over normal transport.
So the clients written in languages for which thrift doesn't support TLS, can connect to the
endpoint which is not exposed over TLS.


> [GSoC] Securing Airavata API
> ----------------------------
>                 Key: AIRAVATA-1624
>                 URL:
>             Project: Airavata
>          Issue Type: New Feature
>          Components: Airavata API
>            Reporter: Suresh Marru
>              Labels: gsoc, gsoc2015, mentor
>             Fix For: WISHLIST
>         Attachments: Securing_ARAVATA_API_V1.pdf
> Apache Airavata uses Thrift based API's for external facing API's and for system internal
CPI's. The API's need to be secured adding authentication and authorization capabilities.

> The Authentication need to ensure only approved users/clients can communicate. Similarly
clients should only interact with valid servers. 
> Authorization need to be enforced to ensure only users with specific roles can appropriately
access specific API's. As an example, administrative roles should be able see all the users
experiments where as end users can only see his/her data and not access other information
(unless explicitly shared). 
> Earlier GSoC project focused on this topic has relavent discussion. 

This message was sent by Atlassian JIRA

View raw message