[
https://issues.apache.org/jira/browse/AIRAVATA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14351822#comment-14351822
]
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 to
AIRAVATA.
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,
Hasini.
> [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)
