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