airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suresh Marru (JIRA)" <>
Subject [jira] [Commented] (AIRAVATA-1624) [GSoC] Securing Airavata API
Date Sat, 07 Mar 2015 21:27:38 GMT


Suresh Marru commented on AIRAVATA-1624:

Hi Hasini,

Can we also consider a scenario 4 (which is a slight variation of Scenario 2 and 3) where
gateway and Airavata needs to communicate via a persistent token (instead of a per user OAuth
token)? Typically in a OAuth approach user id hand holding the trust and allowing Gateway
and Airavata to trust his credentials. In this scenario, the gateway takes care of user authentication
(either with custom user store or through federated identity) and performs some actions on
the gateway portal. Subsequently, some user actions will require Airavata interactions at
which point gateways send user information after authenticating and authorizing through a
one time pre-issued gateway API token (similar to the developer tokens widely used). 

Airavata also supports Desktop applications (and in future mobile apps) in addition to the
Web based gateways. Since your proposed implementation is OAuth centric, will all scenarios
work for desktop and mobile apps?

> [GSoC] Securing Airavata API
> ----------------------------
>                 Key: AIRAVATA-1624
>                 URL:
>             Project: Airavata
>          Issue Type: New Feature
>          Components: Airavata API
>            Reporter: Suresh Marru
>              Labels: gsoc, gsoc2015, mentor
>         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