Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@airavata.apache.org
Date: Mon, 23 Mar 2015 17:41:12 +0000 (UTC)
From: "Hasini Gunasinghe (JIRA)" <jira@apache.org>
To: dev@airavata.apache.org
Message-ID: <JIRA.12780155.1425671042000.8038.1427132472169@Atlassian.JIRA>
In-Reply-To: <JIRA.12780155.1425671042000@Atlassian.JIRA>
References: <JIRA.12780155.1425671042000@Atlassian.JIRA>
 <JIRA.12780155.1425671042314@arcas>
Subject: [jira] [Comment Edited] (AIRAVATA-1624) [GSoC] Securing Airavata
 API
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hasini Gunasinghe edited comment on AIRAVATA-1624 at 3/23/15 5:40 PM:
----------------------------------------------------------------------

Hi Suresh and Airavata Team,

I submitted the project proposal both at google-melange system (http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/hasini_gunasinghe/5649050225344512) and Airawata wiki (https://cwiki.apache.org/confluence/display/AIRAVATA/%5BGSoC+Proposal%5D+Securing+Airavata+API?).
I appreciate your comments and feedback so that I can do any necessary modifications before the deadline on 27th of March.

Couple of things I would like to note:
1. As listed under 5th sprint, I plan to implement a custom federated authenticator for which WSO2 IS does not have out of the box support for, which might be needed by Airavata. Please let me know what are the federated authentication protocols that Airavata might need support for in the order of their priority. For example, as I got to know from our previous discussion, one such protocol would be InCommon. 
2. I planned the 3 months to be spanned from 13th May to 12th August, instead of the official GSoC timeline from 25th May to 24th August as it would align with Airavata release time line as well as my summer plans. Please let me know if there is any concerns. I am flexible to change it to the official timeline.

Thanks & Best Regards,
Hasini.


was (Author: hasinig):
Hi Suresh and Airavata Team,

I submitted the project proposal both at google-melange system and Airawata wiki (https://cwiki.apache.org/confluence/display/AIRAVATA/%5BGSoC+Proposal%5D+Securing+Airavata+API?).
I appreciate your comments and feedback so that I can do any necessary modifications before the deadline on 27th of March.

Couple of things I would like to note:
1. As listed under 5th sprint, I plan to implement a custom federated authenticator for which WSO2 IS does not have out of the box support for, which might be needed by Airavata. Please let me know what are the federated authentication protocols that Airavata might need support for in the order of their priority. For example, as I got to know from our previous discussion, one such protocol would be InCommon. 
2. I planned the 3 months to be spanned from 13th May to 12th August, instead of the official GSoC timeline from 25th May to 24th August as it would align with Airavata release time line as well as my summer plans. Please let me know if there is any concerns. I am flexible to change it to the official timeline.

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)