[
https://issues.apache.org/jira/browse/AIRAVATA-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571974#comment-14571974
]
Hasini Gunasinghe edited comment on AIRAVATA-1624 at 6/4/15 2:04 AM:
---------------------------------------------------------------------
Hi Supun,
Thanks for the comments.
Concerning multi-tenancy, yes, I have considered it when designing the solution
(please refer the 6th comment on this jira). Once the architectural details of
multi-tenanted Airavata is finalized (i.e: how a tenant will be identified, how
the configuration files will be cloned and stored for each tenant etc), current
security manager can be easily extended to support multi-tenancy accordingly.
AuthzToken already contains a properties map for passing user attributes which
can be used to pass the tenant identifier or we can introduce a separate field
based on the tenant identifier that will be used in Airavata.
Concerning the TLS support, thanks for informing that thrift doesn't support
TLS for PHP client. I was anyway planning to make the communication over TLS
configurable, so that any one who prefers performance over security can use the
communication without TLS. For that, we will have two endpoints: one exposed
over TLS and the other one exposed over normal transport. Therefore, the
clients written in languages for which thrift doesn't support TLS, can connect
to the endpoint which is not exposed over TLS.
Thanks,
Hasini.
was (Author: hasinig):
Hi Supun,
Thanks for the comments.
Concerning multi-tenancy, yes, I have considered it when designing the solution
(please refer the 6th comment on this jira). Once the architectural details of
multi-tenanted Airavata is finalized (i.e: how a tenant will be identified, how
the configuration files will be cloned and stored for each tenant etc), current
security manager can be easily extended to support multi-tenancy accordingly.
AuthzToken already contains a properties map for passing user attributes which
can be used to pass the tenant identifier or we can introduce a separate field
based on the tenant identifier that will be used in Airavata.
Concerning the TLS support, thanks for informing that thrift doesn't support
TLS for PHP client. I was anyway planning to make the communication over TLS
configurable, so that any one who prefers performance over security can use the
communication without TLS. For that, we will have two endpoints: one exposed
over TLS and the other one exposed over normal transport. So the clients
written in languages for which thrift doesn't support TLS, can connect to the
endpoint which is not exposed over TLS.
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)
