[GSoC Proposal] Securing Airavata API

Transcription

1 [GSoC Proposal] Securing Airavata API TITLE: Securing AIRAVATA API ABSTRACT: The goal of this project is to design and implement the solution for securing AIRAVATA API. Particularly, this includes authenticating and authorizing end users in to AIRAVATA API. One of the challenges in this project is to design a unified solution which can be easily adapted to set of identified use cases that are based on different identity management scenarios. The proposed solution addresses all such use cases and involves open identity management standards. PROPOSAL CONTENT: Problem Definition: AIRAVATA is used by science gateways as a platform to create, submit, execute and monitor different types of scientific jobs and work flows in scientific grids. In the current architecture (see Figure 1 for a high level overview), the end user who interacts with AIRAVATA APIs through such gateways, is not authenticated or authorized, hence there is no notion of the identity of the end user maintained in AIRAVATA. However, it is a critical requirement in production deployment that only the legitimate users are allowed in and access to different functionalities exposed by AIRAVATA API is controlled based on the privileges of such users and the organizational policies. Attaching user identity with different jobs, work flows and other artifacts created by different individuals is also useful in the perspective of AIRAVATA in order to isolate them based on the user who created them.

2 security. Figure 1: Overview of AIRAVATA deployment without When designing the solution to address the aforementioned requirements, there are three main use cases that we need to support based on how the end user's identity is managed at the gateways: Gateway does not have identity management capability and would like to depend on the identity management features provided by AIRAVATA. Gateway has a user-store and in-house identity management mechanisms. Different gateways might have different preferences on the level at which they share user identity information with AIRAVATA. Gateway authenticates users via some federated identity management protocol such as SAML SSO, OpenID, OAuth, InCommon, etc. The solution should also support multi-tenancy and be applicable to mobile /desktop clients. Solution Overview: Figure 2 illustrates the high level architecture of the proposed solution. Figure 2: High Level Overview of the Solution

3 This solution makes use of the identity management features offered by WSO2 Identity Server (WSO2 IS) which acts as the identity manager of AIRAVATA. Details of the interactions illustrated in Figure 2 are as follows: (numbers correspond to the labels of interactions) User is authenticated to AIRAVATA (how the authentication is performed with regard to aforementioned three different use cases is described in the next section) and OAuth access token is obtained from the WSO2 IS to access the AIRAVATA API on behalf of the authenticated user. Request to AIRAVATA (depending on what action user wants to perform) is sent along with the obtained OAuth access token. Each request sent to AIRAVATA API is authorized before executing any of the API functionality. The first step in authorization is: validating the OAuth access token attached to the request. Second step is: authorizing the request based on the authorization policy which is pre-defined by the gateway administrator (details to follow). Only the authorized requests are served by AIRAVATA API. Authorization of subsequent requests from the same user will be handled using session management and caching of authorization decisions in order to avoid the requirement of contacting the WSO2 IS for authorizing multiple requests by the same user for the same resource. Above solution supports multi-tenancy as when ever the user identity is exchanged, it includes the tenant domain that the user belongs too so that the authentication authorization is performed with respect to that tenant domain. The same client side logic can be implemented in desktop and mobile clients as well so that the above solution is applicable to desktop and mobile clients. Solution in detail: This section elaborates the high level solution presented in the previous section.

4 Authentication: Authentication is the only step in the high level solution that differs among the three different use cases that we identified at the beginning. In what follows I explain how the aforementioned high level solution is adapted to address those three use cases. Use Case 1: Gateway does not have a user-store and would like to depend on the user management features provided by AIRAVATA. In this scenario, the gateway users are stored in the user-store provided by the identity manager of AIRAVATA (i.e: WSO2 IS) as shown in Figure 3. Figure 3: Solution for use case 1. The gateway makes use of the AIRAVATA Client API to create users, which in turn invokes the User Admin API of WSO2 IS. (This is already being implemented in AIRAVATA.) When the users are authenticated to the gateway, their credentials are validated against those stored in the user-store of WSO2 IS. The gateway makes use of the AIRAVATA Client API to authenticate users and obtain OAuth access token. This corresponds to the "resource owner credential" grant type in OAuth.

5 Use Case 2: Gateway has a user-store and in-house identity management mechanisms. Different gateways might have different preferences on the level at which they share user identity information with AIRAVATA. Three solutions are proposed to address this use case and they are ordered based on the order of priority as discussed with the AIRAVATA team. (1). The gateway wants to share only the minimum required information about the end user's identity with AIRAVATA. In this case, the gateway obtains an OAuth access token by authenticating to the identity manager of AIRAVATA (i.e: WSO2 IS). This corresponds to the "client credential" grant type in OAuth. End user requests are sent to AIRAVATA attaching this OAuth access token and the minimum required user identity information required by AIRAVATA API (see Figure 4). Figure 4: Solution for use case 2 - option 1. (2). In the second level at which the gateway is willing to share user identity information; the gateway does not want to connect AIRAVATA to its organizational user store, however, it prefers to provision user accounts to AIRAVATA with the identity information required by AIRAVATA.

6 In this case, the gateway makes use of the identity provisioning client in AIRAVATA client API to provision user accounts to the identity manager of AIRAVATA (i.e: WSO2 IS), at the time of user account creation in the gateway. This enables the execution flow of accessing the AIRAVATA API be the same as in the use case 1 (see Figure 5). 2. Figure 5: Solution for use case 2 - option (3). In the third level at which the gateway is willing to share user identity information; the gateway allows AIRAVATA to connect to its organizational user store in read-only mode. In this case, the identity manager of AIRAVATA (i.e: WSO2 IS), is connected to the gateway's organizational user store through the user store manager extension provided by WSO2 IS. This enables the execution flow of accessing the AIRAVATA API be the same as in the use case 1 (see Figure 6).

7 Figure 6: Solution for use case 2 - option 3. Use Case 3: Gateway authenticates users via some federated identity management protocol such as SAML SSO, OpenID, OAuth, InCommon, etc. In this case, the gateway becomes the relying party and it needs to authenticate users to AIRAVATA through the same authentication mechanism that is being used to authenticate users to the gateway. This can be achieved with the support of federated authenticators in the authentication framework of WSO2 IS 5.0 [1] (see Figure 7). If the gateway needs to support a federated authentication protocol that is not supported out of the box by WSO2 IS 5.0, we write a custom authenticator. If the federated authentication protocol supports retrieval of user's identity attributes from the identity provider, a user account is created in WSO2 IS (i.e: the identity manager of AIRAVATA) with such identity information. Once the user is authenticated to WSO2 IS via the federated identity management protocol, OAuth access token is obtained (for e.g: if the federated authentication protocol is SAML2 SSO; this corresponds to SAML 2.0 Bearer Assertion Profile grant type in OAuth) to access the AIRAVATA API and the rest of the flow of execution continues in the same way as in use case 1. case 3 Figure 7 : Solution for use

8 Authorization: OAuth for authorization delegation and validation of user-authentication: The gateway obtains an OAuth access token from WSO2 IS via in order to send requests to AIRAVATA API on behalf of the authenticated user (different OAuth grant types are used based on the use case as described previously). The gateway makes use of the AIRAVATA Client API to obtain OAuth tokens, which in turn invokes the OAuth token issuer API of WSO2 IS. The gateway can use this token until it expires, avoiding the user having to authenticate each time the user accesses AIRAVATA through the gateway. Enforcing Authorization: All the requests to AIRAVATA go through Security Manager before they hit the actual business logic of AIRAVATA API. As per step 4,5 of the high level solution overview (see Figure 2), authorization is performed in two steps: Validation of the OAuth token attached to the request: This guarantees that the request comes from an authenticated user who has obtained a valid OAuth access token. Authorizing the API request based on the authorization policy which is predefined by the gateway administrator: This guarantees that the authenticated user is only allowed to invoke AIRAVATA API functions and access resources which he/she has permission to. Note: Although above is how the authorization is enforced in the default Security Manager, we make the implementation extensible such that any other Security Manager could also be plugged in easily. XACML for Authorization: XACML is the de-facto standard for fine grained, policy based access control. Policy based access control is more flexible than baking the authorization logic into the code of Security Manager. Administrators of different gateways might have different authorization rules based on their organizational policies. They can be facilitated to define, update and enforce such authorization rules to control access to their instance of AIRAVATA API. The implementation will

9 be based on the fully fledged implementation of XACML reference architecture in WSO2 IS. Three main components of XACML reference architecture that will be used in this solution are: PAP (Policy Administration Point), PDP (Policy Decision Point) and PEP (Policy Enforcement Point). PAP facilitates defining, updating and publishing the authorization policies. Figure 8 illustrates the involvement of PAP for defining the authorization policies by the gateway administrator. The gateway makes use of AIRAVATA client for this which in turn invokes XACML PAP API of WSO2 IS. Gateway Admin Figure 8: Creation of Authorization Policy by PEP (this will be a part of the Security Manager that fronts the AIRAVATA API) is where the authorization is actually enforced on the API requests. Upon intercepting a request sent to AIRAVATA API, the PEP forms a XACML authorization request including the information related to the current API request (such as user identity, name of the API function or resource that was requested) and then it sends that XACML authorization request to the PDP.

10 PDP - which is the XACML policy engine of WSO2 IS, evaluates the authorization request sent by the PEP, against the policy defined by the gateway administrator and returns the authorization decision back to the PEP. Based on this decision, the PEP (in the Security Manager) allows or denies the API request that it intercepted. Securing Communication: It is critical to secure the communication between: (1)gateway and WSO2 IS (2) gateway and AIRAVATA and (3)AIRAVATA and WSO2 IS (see Figure 2). Communication between the AIRAVATA client at the gateway and the WSO2 IS mainly involves the requests (SOAP over HTTP) which invoke the admin services of WSO2 IS (such as User Admin API, Authentication API, OAuth Token Issuer API, XACML PAP API, etc). These requests should be authenticated with the gateway admin-credentials and should be sent over SSL, as per the default settings of WSO2 IS. The same is true for communication between the Security Manager at the AIRAVATA server and the WSO2 IS. This solution proposes that the Thrift calls from the AIRAVATA client at the gateway to the AIRAVATA API should also be made over TLS. Main Components of the Solution: Main components of this solution are identified as: AIRAVATA Client: (which consists of the following sub components) Authentication Client OAuth Client XACML Policy Admin Client Security improvements for the Thrift client which invokes AIRAVATA API Provisioning client Security Manager Manager: OAuth access token validator XACML Policy Enforcement Point (PEP) Custom extension points to WSO2 IS (If out of the box features do not cater the requirements): Custom federated authenticator(s)

11 DELIVERABLES: Implementation of the solution for use case 1, use case 2 - option 1,2 and use case 3. Test cases (both unit and integration tests) and samples as appropriate. Documentation of the security solution for AIRAVATA. TIMELINE AND MILESTONE PLAN (Divided into 2 week sprints): At the end of each two weeks sprint, I will do a demo of the features developed during that sprint. Sprint time line 13th May - 27th May 28th May - 10th June Sprint plan - Completing AIRAVATA API changes. - OAuth access token retrieval and validation (for use case 1). - Defining default XACML policy - XACML PEP client in Security Manager with caching. - Securing communication between client and AIRAVATA API with SSL. 11th June - 24th June - Extend the implementation to support use case 2- option 1. - Session management. - PAP client. 25th June - 8th July - Use case 3 with SAML 2 SSO as the federated authentication mechanism

12 - Use case 3 with Face book login as the federated authentication mechanism 9th July - 22nd July 23rd July - 5th August - Custom authenticator for a federated authentication mechanism that is not supported in WSO2 IS out of the box. - Provisioning client to support use case 2 - option 2 - Provisioning handler for JIT provisioning in use case 3 6th August - 12th August - (1 week) wrap up work and documentation REFERENCES: [1] Prabath Siriwardena. WSO2 Identity Server Authentication Framework. July 2014.