[ 
https://issues.apache.org/jira/browse/AIRAVATA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569004#comment-14569004
 ] 

Suresh Marru commented on AIRAVATA-1624:
----------------------------------------

Hi Hasini,

I am curios of the OAuth grant flows you plan to implement with Airavata API. 
During the CTSC Security review we have hypothetically outlined Airavata use 
cases into the following grant flows:
* Gateways using Airavata's hosted IS instance will use the *Authorization Code 
Grant flow*. 
** Airavata PHP Reference Gateway is a good example for this. 
** Between the user agent (browser) and Airavata a trusted web server mediates. 
* Gateways with native Apps and mobile apps will use *Implicit Grant flow*
** GridChem is an example (Dimuthu's GSoC Project)
** The trusted web server in previous scenario is non-existing for these 
usecases
** Users interact with a local user agent which is in the same trust domain  (a 
desktop app or a mobile app) 
** This is less secure since its easier to fetch token, so the implementation 
has to ensure the API provides limited access. 
* Gateways managing own users uses the *Client Credentials Grant flow*. 
** The users need not know about Airavata, and gateway is trusted by Airavata 
and secured it on their behalf. 

What if your take on the above mapping? 

> [GSoC] Securing Airavata API
> ----------------------------
>
>                 Key: AIRAVATA-1624
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-1624
>             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. 
> https://cwiki.apache.org/confluence/display/AIRAVATA/GSoC+2014+-+Add+Security+capabilities+to+Airavata+Thrift+services+and+clients



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to