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

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: https://issues.apache.org/jira/browse/AIRAVATA-1624
>             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. 
> 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