airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hasini Gunasinghe (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AIRAVATA-1624) [GSoC] Securing Airavata API
Date Tue, 02 Jun 2015 15:09:18 GMT

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

Hasini Gunasinghe edited comment on AIRAVATA-1624 at 6/2/15 3:08 PM:
---------------------------------------------------------------------

Hi Suresh,

There are four core 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.  



was (Author: hasinig):
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)

Mime
View raw message