[
https://issues.apache.org/jira/browse/AIRAVATA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14569238#comment-14569238
]
Hasini Gunasinghe commented on AIRAVATA-1624:
---------------------------------------------
Hi Suresh,
There are four grant types in OAuth: the three mentioned in your comment above,
plus the resource owner credential grant type. In addition, there are extension
grant types such as SAML 2.0 Bearer Assertion Profile.
Please refer http://alexbilbie.com/2013/02/a-guide-to-oauth-2-grants/ for a
good explanation on the different grant types and their use cases.
In this project I have planned to support resource owner credential grant type
(for use case 1), client credential grant type (for use case 2-option 1) and
SAML 2.0 Bearer Assertion Profile (for use case 3).
Actually we have already discussed which OAuth grant types will be supported in
this solution (please refer the last paragraph in the 7th comment on this issue
and the descriptions under each of the use cases in the proposal).
Both Authorization Code grant type and Implicit grant type are web browser
based grant types. You can not use implicit grant type in native apps and
mobile apps unless you have an embedded browser in them. Therefore it is not
good to suggest implicit grant type for gateways with native apps and mobile
apps. Resource owner credential grant type is more suitable for that.
On the other hand, it is also not good to suggest Authorization code grant type
for the case in which Airavata's hosted IS instance and Airavata PHP reference
gateway is used, because in this case, Airavata PHP gateway is already trusted
by the Airavata's hosted IS.
One use case that Authorization code grant type will be useful is when the
gateway admins want to deploy a different authorization server other than
Airavata hosted IS, that doesn't trust Airavata. Even that kind of use case can
be supported from Airavata side with the existing security manager. You only
need to implement the flow of the Authorization code grant type at the client
side.
Thanks,
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
> 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)
