airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Supun Chathuranga Nakandala (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-1624) [GSoC] Securing Airavata API
Date Wed, 03 Jun 2015 17:53:38 GMT


Supun Chathuranga Nakandala commented on AIRAVATA-1624:

Hi Hasini,

I went through the documents and code and have few concerns

As far as I understood in the current implementation when validating OAuth tokens you have
considered only the single gateway - single IS - single airavata scenario. But in the current
airavata deployments we have only one identity server where each gateway is a tenant and airavata
is planning to become a multi-tenanted service. So ideally all gateway traffic should be able
go via one API and I think the OAuth validation should happen based on tenant basis using
respective tenant admin credentials and also AuthzToken should contain some tenant id field
to resolve the tenant.

Also in the proposed work for sprint two I see you are planning to implement TLS support for
Airavata Thrift communications. Thrift supports TLS for java and several other languages like
python but not for all the languages. And specially not for PHP yet. So I think we should
defer this task as this will make all PGA communication to break. There is an open issue in
Thrift jira. It also has a sample patch and someone has claimed that it worked for him. But
we may need to properly test those if plan to incorporate them.


> [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