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 Sat, 07 Mar 2015 22:40:38 GMT


Hasini Gunasinghe commented on AIRAVATA-1624:

Hi Suresh,

Concerning the first question: let me reiterate scenario 4, just to be sure that I understood
it correct from your description.
Gateway obtains a token to access AIRAVATA API by authenticating to it as a gateway user through
a dedicated user account.(which does not correspond to a real end user of the gateway). And
whenever a real end user performs some actions on the gateway portal which needs to invoke
AIRAVATA API, the gateway sends those requests to AIRAVATA API along with that pre-obtained
token, without authenticating the real end user to AIRAVATA. 

If I understood scenario 4 correct, the proposed solution can be adapted to address this scenario.
The gateway authenticates to AIRAVATA through a dedicated user account and obtains an OAuth
token to access AIRAVATA API (lets say this is step 0 in the solution illustrated in Figure
1). This corresponds to the 'client credential' grant type in OAuth terms.
Then when a request is sent to AIRAVATA API as a consequence of some action performed by a
real end user at the gateway, the steps 1 and 2 in Figure 1 will be omitted. The request to
AIRAVATA is  sent attaching the pre-obtained OAuth token by the gateway (step 3 in Figure
1). Then the Authorization Manager at AIRAVATA validates the request in the same way as it
is described in the proposed solution. In this case, the actual end user's identity is unknown
Using gateway admin's account to obtain this token is not recommended because then the requests
will be authorized based on admin privileges. That is why I mentioned it as a dedicated user
account maintained by gateway at AIRAVATA (i.e in WSO2 IS) with appropriate privileges assigned.

Concerning question 2, the proposed solution equally applies to desktop clients as well as
mobile clients. There are grant types in OAuth which are not specific to web browser based
application and we use such grant types in this solution (e.g: resource owner credential grant
type, extensions of it and client credential grant type, depending on the scenario).

Thanks & Best Regards,

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