CCTS 2.0 Security Architecture Analysis

From CTMS_WIKI

Introduction

Background

The caBIG Clinical Trials Suite (CCTS) is an enterprise clinical trials system being designed primarily for use in trial sites. The suite is comprised of a collection of interoperable modules covering a broad range of key areas in cancer clinical trials management. These include patient registration via C3PR, patient scheduling via PSC, adverse events reporting via caAERS, lab analysis via LabViewer, and clinical data management via C3D. Integration between these applications is centered around five key scenarios: Study Creation, Register Subject, Load Labs in CDMS, Lab-driven AE Creation, and AE-Triggered Schedule Change. The implementation is based upon the caGrid infrastructure with caXchange as the Enterprise Service Bus for reliable message routing and GAARDS providing robust security.

Scope

This document represents an analysis of architectural approaches for the CCTS 2.0 security architecture. It is a precursor to the CCTS Security Architecture, which describes the approach implemented.

This document is a work in progress used strictly for planning for the CCTS 2.0 release. Up until that release, it could be altered in any way.

Related Documentation

Requirements

Architectural Considerations

The security requirements require that a number of considerations are made at the architectural level:

• Data Transport: moving data between components programatically in a secure way
• Data Privacy: data being passed between components should be encrypted or otherwise obfuscated such that if it is intercepted it cannot be read
• Identity Management: a component for creating, updating, and removing users
• Trust: maintaining authorities of information, such as certificate authorities
• Authentication: validating that a user is who they claim to be
• Role Management: creating, updating, removing, adding users, and removing users from roles across applications and organizations
• Authorization Policies: based on the role of the user, what can actions can they perform within an application
• Single Sign-on: once a user is logged into one application they should not have to log into another, and once a user is logged out of one application they should not be logged into another
• Delegation: the act by which a user determines which components can act on their behalf
• Integration: a way to bridge the security components with the applications themselves in a seamless way that minimizes developer and adopter effort

The following sections describe the need for implementing these considerations and their motivation in more detail.

Data Transport

While a data transport mechanism is itself not a security consideration, the mechanism must itself be amenable to the security architecture. For example, a mechanism that does not allow for data integrity should not be implemented/leveraged. Further analysis of the data transport mechanism not related to security (e.g. existing standards, reliability, etc.) is out of the scope of this document.

Data Privacy

Data that is exchanged between two components must be kept secure. That is, the recipient of the data should be the only entity able to read it. This is a basic requirement of any system that exchanges sensitive data, such as the Personal Health Information (PHI) that is exchanged in CCTS. A common approach to insuring data integrity is by exchanging data over a secure channel whereby all data is encrypted, often with a public/private key strategy.

Identity Management

Identity management is essentially the process by which users are managed electronically. Their identity is often tied to a user name and secured via a secret password that only they know. Many organizations already have infrastructure in place to manage user identities, so the security infrastructure should be able to leverage this. However, in the case that such infrastructure does not already exist, CCTS should provide identity management out of the box. Furthermore, user management should be controlled centrally. For example, a user should be provisioned once and be known to the system such that if they have the appropriate cross-application privileges they should be able to access all of the applications without their identity having to be provisioned in each application.

A special case of identity management is that of host identities. In some cases, it is not sufficient to merely identify users, but all actors in a system should be able to be identified. One key actor is that of a host, or service, that is exchanging data. In some cases, it may be important to mutually authenticate both the sender and receiver of data.

Trust

In some cases, it is important that a component is able to determine whether another component is an authority for a particular assertion. For example, trust could exist between a service and a certificate authority that signed a credential. Another example of trust is between two components exchanging data. The component receiver could trust that the sender appropriately authenticated and authorized the user.

Authentication

Authentication is the process by which a component determines that a user is who they claim they are. In many cases, this is handled by a user providing a user name (which is tied to their identity) and a password (which is a secret phrase that only the user and the component know). Another example of authentication is when a component shares a public key that has been issued by a trusted authority.

Role Management

Roles must be managed centrally in order to avoid the situation where a user must be provisioned in each application and assigned a role in each application. Furthermore, these roles must be assignable at the organization and study level to meet CCTS authorization use cases. A common set (or as common as possible) of roles is desirable.

Authorization Policies

Once an application knows a user's role, they then can make decisions on the actions a user can take within that application. This policy on what actions a role can and cannot take should encoded locally within each applications because it is unique to the application (and changes more frequently than roles).

SSO

Single sign-on is the process by which a user logs into a system once and does not need to login to a set of applications again until the user signs out or the session is terminated. This is a primary requirement of the CCTS security infrastructure.

Single sign-out is the process by which a user logs out (or is logged out) of the system and no longer has access to ANY of the applications that are participating in SSO. This is a secondary requirement of the CCTS security infrastructure.

Delegation

In a federated environment, it is often necessary for different components to act on the user's behalf. The process by which a user determines which components and how there credentials are to be used is called delegation. There is a clear need for delegation in CCTS because of the federated, pluggable, and auditable nature of CCTS. The first case is in the situation where different CCTS systems are managed independently of each other. While the current use cases indicate that authorization is homogeneous throughout each workflow (e.g. a registrar creating a registration in C3PR has the permissions to create a subject and registration in each other application), this may not be the case in a cancer center production deployment. There could be the case that the registration module (C3PR) is owned by the registration office while the adverse event system is owned by the reporting office. Another clear requirement for delegation stems from the pluggable nature of CCTS, where a third party system may take the place of a caBIG-developed system. In this case, the third party system may need the user's credentials in order to authorize the user and perform particular actions within the system. In yet another situation, there is a clear need to provide an audit trail throughout the entire set of CCTS workflows and tools. When a user takes an action in C3PR that results in actions in caXchange and downstream systems, a clear audit trail of who is performing these actions is required. This is further compounded in the case of multi-site trials, where a distal site may be receiving messages from any number of other sites and needs to keep track of which users are taking actions within their systems.

Integration

While not a security requirement, there is a clear need to make it as seamless and easy as possible for developers to integrate the security components into their application.

Existing Solutions

CSM

In CCTS 1.5, each application leverages the Common Security Module (CSM) to manage users, roles, and privileges. CSM is backed by a relational database and provides a set of APIs that applications (and other components) can use to manage security. The authentication framework is pluggable, allowing for other identity providers (such as LDAP) to be plugged in. Authorization policies are expressed using the following constructs:

• User: Someone that requires access to an application. Users can become part of a Group, and can have associated Protection Group and Roles.
• Group: A collection of application users. By combining users into a Group, it becomes easier to manage their collective roles and access rights in your application.
• Protection Element: Any entity (typically data) that has controlled access. Examples include Social Security Number, City, and Salary. Protection Elements can also include operations, buttons, links, etc.
• Protection Group: A collection of application Protection Elements. By combining Protection Elements into a Protection Group, it becomes easier to associate Users and Groups with rights to a particular data set. Examples include Address and Personal Information.
• Privilege: Refers to any operation performed upon data. CSM makes use of a standard set of privileges, which aids in standardizing authorization to comply with JAAS and Authorization Policy and allows for adopting technology such as SAML in the future.
• Role: A collection of application Privileges. Examples include Record Admin and HR Manager.

Leveraging the CSM allows us to meet many of the security requirements outlined for CCTS. However, it falls short in the following areas:

• Secure Communication: the CSM is scoped to supporting authentication and authorization and makes no provisions for securing data exchange or tying user identities to data exchange.
• Centralized Management: while there is nothing to prevent a centralized CSM to be deployed and leveraged across applications, it would be technically challenging to identify a set of common privileges across all applications (as opposed to a set of common roles, which is more tractable).
• Cross-institutional Identity Management: the CSM makes no assumptions about how user identities are scoped. In some sense this is a positive feature because it allows application developers to scope the users however they choose. However, it does mean that there is no infrastructure provided for managing users in a cross-institutional way.

Therefore, the CSM is not a completely sufficient solution to meet all of the CCTS security requirements, though it does provide some key benefits.

Grid Security

The Grid Authentication and Authorization with Reliably Distributed Services (GAARDS) provides services and tools for the administration and enforcement of security policy in an enterprise Grid. GAARDS was developed on top of the Globus Toolkit and extends the Grid Security Infrastructure (GSI) to provide enterprise services and administrative tools for:

1. grid user management
2. identity federation
3. trust management
4. group/VO management
5. Access Control Policy management and enforcement
6. Integration between existing security domains and the grid security domain.

GAARDS services can be used individually or grouped together to meet the authentication and authorization needs for Grids. Below is a list of some of the core services provided by GAARDS:

• Dorian – A grid service for the provisioning and management of grid users accounts. Dorian provides an integration point between external security domains and the grid, allowing accounts managed in external domains to be federated and managed in the grid. Dorian allows users to use their existing credentials (external to the grid) to authenticate to the grid.
• Grid Trust Service (GTS) - The Grid Trust Service (GTS) is a grid-wide mechanism for maintaining and provisioning a federated trust fabric consisting of trusted certificate authorities, such that grid services may make authentication decisions against the most up to date information.
• Grid Grouper - Provides a group-based authorization solution for the Grid, wherein grid services and applications enforce authorization policy based on membership to groups defined and managed at the grid level.
• Credential Delegation Service (CDS) - A WSRF-compliant Grid service that enables users/services (delegator) to delegate their Grid credentials to other users/services (delegatee) such that the delegatee(s) may act on the delegator's behalf.
• Web Single Sign On (WebSSO) - Provides a comprehensive, Single Sign On (SSO) solution for web applications using GAARDS.
• Authentication Service - Provides a framework for issuing SAML assertions for existing credential providers such that they may easily integrated with Dorian and other grid credential providers. The authentication service also provides a uniform authentication interface in which applications can be built on.
• Common Security Module (CSM) - Provides a centralize approach to managing and enforcing access control policy authorization.

CCTS leverages the caGrid security infrastructure to provide communication level security, as well as authentication and an integration with authorization. The following depicts a high-level overview of caGrid security infrastructure:

CCTS includes the following components:

• GTS for managing trust between services that are exchanging messages
• Dorian for provisioning users, authentication, and obtaining a user certificate from user credentials
• CDS for managing delegated credentials and policies
• WebSSO for managing single sign-on sessions (not depicted)
• Common Security Module for connecting local security policies with the grid components (not depicted)

Industry Standards

PKI

In cryptography, a public key infrastructure (PKI) is an arrangement that binds public keys with respective user identities by means of a certificate authority (CA). The user identity must be unique for each CA. The binding is established through the registration and issuance process, which, depending on the level of assurance the binding has, may be carried out by software at a CA, or under human supervision. The PKI role that assures this binding is called the Registration Authority (RA) . For each user, the user identity, the public key, their binding, validity conditions and other attributes are made unforgeable in public key certificates issued by the CA.

PKI arrangements enable computer users without prior contact to be authenticated to each other, and to use the public key information in their public key certificates to encrypt messages to each other.

caGrid leverages PKI to authenticate identities and encrypt data.

Grouper

Grouper is an Internet2 project designed to function as the core element of a common infrastructure for managing group information across integrated applications and repositories. Grouper combines multiple sources of group information, both automated and manual, in managing memberships and other group information in a Groups Registry, a central information asset complementary to a site's Person Registry. A few of the benefits of a groups management service, such as Grouper, include:

• the same groups are made available to many applications
• distributed authorities are able to directly manage access information
• sophisticated group management capabilities, such as subgroups and composite groups, to support many access management needs.
• common user, web services, command line, and java interfaces for managing groups

In addition to basic group management and search capabilities, Grouper's design includes support for: basic group management by distributed authorities; subgroups; composite groups (whose membership is determined by the union, intersection, or relative complement of two other groups); custom group types and custom attributes; traceback of indirect membership; delegation.

The caGrid GridGrouper project leverages Grouper to manage grid groups.

CAS

The JA-SIG Central Authentication Service (CAS) provides enterprise single sign on service, which is a session/user authentication process that allows a user to provide his or her credentials once in order to access multiple applications. The single sign on authenticates the user to access all the applications he or she has been authorized to access. It eliminates future authenticaton requests when the user switches applications during that particular session.

Web Single sign on works strictly with applications accessed with a web browser. The request to access a web resource is intercepted either by a component in the web server, or by the application itself. Unauthenticated users are diverted to an authenticaton service and returned only after a successful authentication.

CAS has the following key benefits:

• An open and well-documented protocol
• An open-source Java server component
• A library of clients for Java, .Net, PHP, Perl, Apache, uPortal, and others
• Integrates with uPortal, BlueSocket, TikiWiki, Mule, Liferay, Moodle and others
• Community documentation and implementation support
• An extensive community of adopters

The caGrid CDS and WebSSO projects leverage CAS to provide delegation and SSO capabilities.

Acegi

Acegi Security is an open source project that provides comprehensive authentication and authorisation services for enterprise applications based on The Spring Framework. Acegi Security can authenticate using a variety of pluggable providers, and can authorise both web requests and method invocations. Acegi Security provides an integrated security approach across these various targets, and also offers access control list (ACL) capabilities to enable individual domain object instances to be secured. At an implementation level, Acegi Security is managed through Spring's inversion of control and lifecycle services, and actually enforces security using interception through servlet Filters and Java AOP frameworks. In terms of AOP framework support, Acegi Security currently supports AOP Alliance (which is what the Spring IoC container uses internally) and AspectJ, although additional frameworks can be easily supported.

Many products in CCTS leverage Acegi to plug into CAS and CDS, including C3PR, caAERS, and PSC.

Architecture Approach

Architectural Overview

It is necessary to provide an architecture that is flexible enough to meet the stringent demands that CCTS places on security (identity management, authentication, authorization, trust, etc.), yet also requirement set by a local, intra-organizational deployment to be simple and have a small footprint and meet the grid, cross-organizational deployment requirements of federated security. Therefore, CCTS could leverage two distinct, yet overlapping security architectures for these two deployment scenarios. The intra-organizational (termed Local) architecture involves leveraging PKI for encrypting data, CSM for identity management and product-based authorization, Grouper to express cross-application roles, CAS for SSO and delegation, and Acegi for connecting to web applications. The inter-organizational (termed Grid) architecture leverages PKI for mutual authentication and data encryption, the AuthenticationService and Dorian for identity management, GTS for trust, GridGrouper to express cross-application and cross-institutional roles, CDS and WebSSO for delegation and WebSSO, and CSM for product-based authorization. These two architectures are distinct in their deployments but overlapping in some of the technologies they leverage. The following sections describe these architectures in more detail.

Local Architecture

The local architecture leverages the following components to meet the CCTS intra-organizational requirements:

• Data Transport: caGrid Services without mutual authentication
• Data Privacy: HTTPS
• Identity Management: central CSM (or other IdP)
• Trust: implicit
• Authentication: central CSM (or other IdP)
• Role Management: Grouper
• Authorization Policies: local CSM
• Single Sign-on/out: WebSSO (with modifications)
• Delegation: CAS tickets
• Integration: Acegi (optional)

Data Transport

CCTS will leverage caGrid Services with transport security enabled and mutual authentication disabled for all messaging. caGrid services are nothing more than WSRF compliant web services with additional functionality, so it is no different than leveraging Axis web services (Globus/caGrid actually uses Axis under the hood). The primary benefit of this approach is that itallows us to leverage the existing service infrastructure such that we do not have to maintain two different services layers. Enabling transport level security will insure that data integrity is maintained through standard SSL encryption. Disabling mutual authentication removes the need to issue a host certificate for the sender, relieving the infrastructure of using any caGrid security infrastructure. The impact of this is that all grid services in CCTS will need to include a configuration step in the installation procedure to properly configure the security configuration files.

Data Privacy

As mentioned in the Data Transport section above, data integrity will be maintained through transport-level security in the web services (SSL over HTTPS).

Identity Management

Identity management must be managed centrally, but it also must be pluggable to the authentication scheme used by the SSO component (CAS). In CCTS, out of the box we leverage a central CSM to manage identities. The only responsibility of this CSM is to manage users and their passwords, as well as authenticating users through a plugin to CAS. Organizations can alternatively leverage any Identity Provider (IdP) they wish, such as LDAP. CAS supports a wide range of IdPs.

All user attributes (name, address, etc.) are stored in the Person service of COPPA, which is tied to users in CSM through the user name (email address).

Trust

In local mode, trust in CCTS is implicit amongst the components exchanging data. There is not provision for maintaining trust because of the closed environment behind the institutional firewall. caXchange maintains a controlled set of components that it forwards messages to, and organizations should understand that they should not forward messages to components that they do not control.

Authentication

Authentication is handled by any IdP that is plugged into CAS. In CCTS, we leverage a centralized CSM to perform authentication via a CAS PasswordHandler. Organizations can plug any PasswordHandler they would like into CAS to perform authentication.

Role Management

In CCTS, roles are managed centrally using Grouper. They are organized by root, site, and study to meet the various administrative, structural, and functional roles. For example, a Grouper structure may look like this:

• Root
  • Roles
    • System Administrator
      • jdoe@duhs.duke.edu
• Organizations
  • NCI0045 (Duke University Health System)
    • Roles
      • System Administrator
        • jdoe@duhs.duke.edu
        • cbrown@duhs.duke.edu
      • Study Coordinator
        • tfrown@duhs.duke.edu
      • Registrar
        • bgates@duhs.duke.edu
    • Studies
      • DUKE0023 (PANVAC)
        • Study Coordinator
          • jharris@duhs.duke.edu
        • Registrar
          • ikilling@duhs.duke.edu
  • NCI2234 (Wake Forest Cancer Center)
    • Studies
      • DUKE0023 (PANVAC)
        • Registrar
          • iloving@wfsu.edu

Authorization Policies

While roles are centrally managed and common across applications, authorization policies themselves unique to applications and thus managed individually. Each application leverages a CSM database locally to managed these policies by mapping roles to privileges. Applications will manage authorization decisions using a process such as this:

1. User accesses application
2. Application authenticates user, getting the user from a CAS ticket
3. User attempts action in application
4. Application looks up roles from Grouper based on user id
5. Application looks up privileges for action
6. Application determines whether given role has the appropriate privileges

As you can see, applications manage only roles and policies (privileges) within their database - they do not store local users whatsoever.

SSO

Single sign-on is implemented using CAS, which will redirect the user to a central login page, generate an SSO ticket, and redirect the user back to the initial application. In addition, single sign-out will also be implemented using CAS, which sends a POST when a session expires to each application participating in SSO. The application will then end the session with the user.

Delegation

Delegation will also be handled by exchanging CAS tickets with message payloads. While this has some technical drawbacks, such as not having a central authority to manage delegation policies, it does meet some of the core requirements of CCTS delegation associated with the pluggable and auditable nature of CCTS. Essentially, each time a message is exchanged between two components, the CAS ticket is included, which identifies the user and the CAS service. It is the responsibility of the receiving component to validate the ticket before extracting the user identity, getting the user's roles, authorizing the action, and then acting on the payload. In the case where the credential is delegated (i.e. the receiving component is going to act on the behalf of the user), the message it sends should include the CAS ticket. This allows subsequent components downstream in the workflow to perform the same validation and authorization activities.

Integration

Acegi will be used where appropriate to integrate with CAS.

Grid Architecture

The grid architecture leverages the following components to meet the CCTS inter-organizational requirements:

• Data Transport: caGrid Services
• Data Privacy: HTTPS
• Identity Management: central CSM (or other IdP)
• Trust: GTS/SyncGTS
• Authentication: AuthenticationService (CSM or other IdP)
• Authorization Policies: local CSM
• Role Management: GridGrouper
• Single Sign-on/out: WebSSO
• Delegation: CDS
• Integration: Acegi (optional)

Data Transport

In the Grid setting, all data exchange will be performed over caGrid services. This will allow mutual authentication of client and service, as well as an easy plugin to the GAARDS infrastructure.

Data Privacy

Data integrity will be maintained through the exchange of data over secure channels. SSL over HTTPS will be used to encrypt all data exchanged between components.

Identity Management

Identity management must be managed centrally, but it also must be pluggable to the authentication scheme used by the SSO component (WebSSO). In CCTS, out of the box we leverage a central CSM to manage identities. The only responsibility of this CSM is to manage users and their passwords, as well as authenticating users through a plugin to WebSSO. An AuthenticationService wrapper will be used to expose the CSM IdP to the grid. Using this strategy, organizations can alternatively leverage any Identity Provider (IdP) they wish, such as LDAP. An alternative strategy is to use Dorian as the IdP. However, to be congruent with the Local Architecture, a local CSM is leveraged. This is also a more desirable solution if a centralized (not locally deployed) Dorian is leveraged for managing grid users.

All user attributes (name, address, etc.) are stored in the Person service of COPPA, which is tied to users in CSM through the user name (email address).

Trust

GTS and SyncGTS are leveraged to manage trust across all of the components.

Authentication

Authentication is handled by any IdP that is plugged into WebSSO. In CCTS, we leverage a centralized CSM to perform authentication via a caGrid AuthenticationService wrapper. Organizations can plug any AuthenticationService they would like into WebSSO to perform authentication.

Role Management

In CCTS, roles are managed centrally using GridGrouper. In the same fashion as the Local Architecture, they are organized by root, site, and study to meet the various administrative, structural, and functional roles. See the Local Architecture Role Management section for a detailed example.

Authorization Policies

Authorization policies are handled identically between the Local and Grid Architectures. Each application maintains a local, unique CSM that maps roles to privileges.

SSO

Single sign-on is implemented using WebSSO, which will redirect the user to a central login page, generate an SSO ticket, and redirects the user back to the initial application. In addition, single sign-out will also be implemented using WebSSO, which sends a message when a session expires to each host participating in SSO. The application will then end the session with the user.

Delegation

Delegation will be implemented with CDS, which provides a central service to managing a user's delegation policy and delegated credential.

Integration

Acegi will be used where appropriate to integrate with WebSSO (via CAS).

Architecture Comparison

The Local and Grid Architectures have some overlapping goals and specific constraints. In the Local Architecture:

• All data should remain within organizational boundaries because user identities are not tied to an organization and there is no trust fabric
• Service invocation does not leverage a true user credential for mutual authentication, but instead relies on an implicit trust that CAS tickets cannot or will not be forged
• Delegation does not leverage a true user credential nor associates a delegation policy with the credential (CAS ticket)

In the Grid Architecture:

• A PKI-trust fabric must be established to insure certificate issuers are trusted
• Host credentials must be issued and used to enable mutual authentication and delegation
• A centralized grid user management service must be used to issue user certificates (Dorian)
• A centralized service must be used to manage delegation policies (CDS - also manages SSO sessions)

The components to meet these goals and constraints are:

Architecture Simplifications

One of the motivations of leveraging a Local Architecture versus the Grid Architecture is that there is a general feeling that the Grid Architecture is "heavy weight" and "burdensome to deploy". To alleviate this, the infrastructure is centralized and the installation procedure is simplified.

Grid Infrastructure Centralization

In most cases, it is not necessary for an organization to deploy all of the security components. This greatly reduces the overhead of deployment and maintenance of CCTS. The following components will be centralized at NCI wherever possible:

• Dorian
• GTS
• GridGrouper
• CDS

In this case, the only local security infrastructure that must be deployed is:

• Central CSM (or other IdP) with AuthenticationService wrapper
• WebSSO
• SyncGTS

Grid Infrastructure Deployment

Currently, the grid infrastructure deployment is complicated by deployment to multiple containers hosted by multiple system users on separate hardware. While this is not useless division of concerns, it greatly complicates to deployment with little or no added security benefit. Therefore, the deployment procedure and architecture has been simplified in the following ways:

1. A wizard-like installer is leveraged to configure the "target grid" before any caGrid component is deployed or configured. This will greatly reduce the errors made during the deployment and configuration process by pre-filling most of the fields.
2. All caGrid components (save WebSSO) are deployed to the same container
3. A WebSSO installer is used rather than a manual process
4. The trust fabric is simplified by providing a single credential for CDS/CAS

Recommendations

Two primary architectures were proposed: "Local Architecture" and "Grid Architecture". They both have their respective advantages and disadvantages. Of the goals of the security architecture, primary to adoptability are that they have a minimal footprint (few deployed components, little management overhead, etc.), meet all of the core security requirements (data privacy, centralized user provisioning, etc.), and support federated security should an adopting center need it. Both architectural approaches meet the core security requirements by design. However, the local security mode is by itself not sufficient to meet the security needs of a distributed environment, whereas the grid security mode does. For example, the local security mode does not provide for federated trust management, federated user identities, etc. Therefore, the only two options are to support both security architectures or just support the grid security architecture. If the local security architecture provided a significantly smaller footprint than the grid security architecture, then it may make sense to support both. However, in the Architectural Simplifications section, the proposed centralization of a number of caGrid components actually provides the grid security architecture with a smaller footprint than the local architecture. Therefore, it is the recommendation of this analysis that the centralized grid security architecture be adopted by CCTS for the 2.0 effort.