![](media/image1.png){width="2.1041666666666665in"
height="0.5in"}![](media/image2.jpeg){width="0.5013888888888889in"
height="0.5013888888888889in"}

![](media/image3.png){width="1.2090277777777778in"
height="1.1416666666666666in"}
![](media/image4.png){width="1.2506944444444446in"
height="1.0083333333333333in"}

caCORE SDK / CSM

SDK/CSM Implementation Changes for caGRID

> Version No: 0.2
>
> Last Modified: 2/26/2006
>
> Author: Satish Patel, Kunal Modi
>
> Team: caCORE SDK/CSM
>
> Client: National Cancer Institute - Center for Bioinformatics,
>
> National Institutes of Health,
>
> US Department of Health and Human Services
>
> This document was prepared for\
> NCI Center for Bioinformatics, pursuant to the caCORE Software
> Development Kit (SDK)\
> Enhancement project.(REF: Solicitation No. S06-234).

# Document History {#document-history .unnumbered}

## Document Location

> The most current version of this document is located in CVS under
> cacoresdk/Project/SDK v3.2.0.1/Development/Design

## Revision History

  -------------------------------------------------------------------------------
  **Version   **Revision   **Author**         **Summary of Changes**
  Number**    Date**                          
  ----------- ------------ ------------------ -----------------------------------
  0.1         2/19/07      Satish Patel       Initial draft

  0.2         2/26/07      Satish Patel,      Added section 4 and 5
                           Kunal Modi         

                                              

                                              

                                              

                                              
  -------------------------------------------------------------------------------

## Review

  ------------ --------------- ------------- ------------ ---------------------
  **Name**     **Team/Role**   **Version**   **Date       **Reviewer Comments**
                                             Reviewed**   

                                                          

                                                          

                                                          

                                                          

                                                          
  ------------ --------------- ------------- ------------ ---------------------

## Related Documents

> **More information can be found in the following related documents:**

  -----------------------------------------------------------------------
  **Document Name**

  -----------------------------------------------------------------------

# Table of Contents {#table-of-contents .unnumbered}

[Document History 2](#document-history)

[0.1 Document Location 2](#document-location)

[0.2 Revision History 2](#revision-history)

[0.3 Review 2](#review)

[0.4 Related Documents 2](#related-documents)

[Table of Contents 3](#table-of-contents)

[Table of Figures 5](#table-of-figures)

[1. Introduction 6](#introduction)

[1.1 Purpose 6](#purpose)

[1.2 Intended Audience 6](#intended-audience)

[1.3 Scope 6](#scope)

[1.4 Overview 6](#overview)

[1.5 Definitions, Acronyms, and Abbreviations
6](#definitions-acronyms-and-abbreviations)

[2. SDK 3.2 Security 7](#sdk-3.2-security)

[2.1 Overview 7](#overview-1)

[2.2 Security implementation in the Java API
7](#security-implementation-in-the-java-api)

[2.3 Known limitations of current implementation
8](#known-limitations-of-current-implementation)

[3. Proposed Changes in SDK 3.2 Security for caGRID Compatibility
9](#proposed-changes-in-sdk-3.2-security-for-cagrid-compatibility)

[3.1 Known Requirements 9](#known-requirements)

[3.2 Possible approaches to implement the requirements
9](#possible-approaches-to-implement-the-requirements)

[3.3 Dynamic Proxies based implementation
9](#dynamic-proxies-based-implementation)

[3.4 TheadLocal based implementation
9](#theadlocal-based-implementation)

[3.4.1 CORESystem.properties 10](#coresystem.properties)

[3.4.2 ClientSession 11](#clientsession)

[3.4.3 Known limitations 11](#known-limitations)

[3.4.4 Additional steps required for caGRID integration
11](#additional-steps-required-for-cagrid-integration)

[3.4.5 List of Files to be Modified 11](#list-of-files-to-be-modified)

[4. Security in Thick Client 12](#security-in-thick-client)

[4.1 Known Requirements 12](#known-requirements-1)

[4.2 Current Implementation of Thick Client
12](#current-implementation-of-thick-client)

[4.3 Limitation of Current Implementation
12](#limitation-of-current-implementation)

[4.4 Proposed Approach 13](#proposed-approach)

[4.4.1 CORESystem.properties 13](#coresystem.properties-1)

[4.5 Limitations of Proposed Approach
14](#limitations-of-proposed-approach)

[4.5.1 Additional steps required for caGRID integration
14](#additional-steps-required-for-cagrid-integration-1)

[4.6 List of Files to be modified 14](#list-of-files-to-be-modified-1)

[5. CSM Enhancements for caGRID Integration
15](#csm-enhancements-for-cagrid-integration)

[5.1 Upgrading the CSM/caGRID Integration Code Base
15](#upgrading-the-csmcagrid-integration-code-base)

[5.2 Integrating the new Installation process for CSM in SDK generated
system
15](#integrating-the-new-installation-process-for-csm-in-sdk-generated-system)

[5.3 Integrating the new Installation process for CSM in the CSM /
caGrid Integration
16](#integrating-the-new-installation-process-for-csm-in-the-csm-cagrid-integration)

[5.4 Configurable Authentication and Authorization for an SDK generated
System
17](#configurable-authentication-and-authorization-for-an-sdk-generated-system)

[5.5 Changes to the caGrid Tools and Services
18](#changes-to-the-cagrid-tools-and-services)

# Table of Figures {#table-of-figures .unnumbered}

[Figure 1: Client Application using a Secured API generated with caCORE
SDK 7](#__RefHeading___Toc160512113)

[Figure 2: Client Application using a Secured API generated with caCORE
SDK 10](#__RefHeading___Toc160512114)

[Figure 3: Thick Client Communication in caCORE SDK
12](#__RefHeading___Toc160512115)

[Figure 4: Thick Client Application using a Secured API generated with
caCORE SDK 13](#__RefHeading___Toc160512116)

# Introduction

## Purpose

Purpose of this document is to discuss the implementation of the CSM
security in SDK 3.1/3.2 and recommend a technical design that would
allow user to configure the security policy such that SDK generated
client can be effectively used with caGRID inside the web container when
the CSM security is enabled.

## Intended Audience

The intended audience for this document includes Developers and
Architects interested in the obtaining an overview of security
implementation works in the caCORE SDK.

## Scope

The scope of this document is limited to a discussion of the current
security implementation within the caCORE SDK with one possible way to
overcome the limitation. A discussion related to using external APIs and
tools is beyond the scope of the document.

## Overview

The following sections first provide a brief overview of how the
security was initially developed in caCORE SDK. Subsequent to the
initial design, it describes the limitation of the current approach and
a design is proposed to overcome the known limitations. In the later
section, it also provides a list of possible changes and implications on
the client to use the new system.

Section 2 of the document describes the current implementation of
security in the SDK remote client. In section 3 various approaches to
resolve the known problem with remote client security is discussed along
with the design specification for one of such approaches. In section 4,
implementation of security in Thick client is discussed. Following to
that in section 5, CSM security enhancement to support caGRID is
discussed with integration steps to be performed by caGRID team.

## Definitions, Acronyms, and Abbreviations

All definitions, acronyms, and abbreviations are provided in the
centralized definition document found at cacoresdk/Project/SDK
v3.2/Miscellaneous/Acronyms.doc.

# SDK 3.2 Security

## Overview

caCORE SDK generated application can be secured or unsecured depending
upon the user's preference selected at the build time. If the user
elects to create a secured application then Common Security Module (CSM)
is being leveraged to perform authentication and authorization on the
server side. Security in the generated system however is implemented in
a proprietary manner. In SDK 3.2, the security was implemented in all
the three different interfaces available to access the data. i.e. 1) Web
interface 2) web service interface and 3) Java API interface. The web
interface and the web service interface are secured using the
intercepting filter on the server side. The client is responsible to
include the security credentials in URL (in case of web interface) or in
the request header (in case of web service). Security implementation in
the Java API is being implemented as described in the following
subsection.

## Security implementation in the Java API

![](media/image5.wmf){width="7.248611111111111in" height="5.1in"}

[]{#__RefHeading___Toc160512113 .anchor}Figure 1: Client Application
using a Secured API generated with caCORE SDK

Client of the SDK generated system is required to follow a specific
protocol to access data from a secured system. The protocol of accessing
data consist of a series of steps as described below

1.  Initialize ApplicationService *(ApplicationServiceProvider.
    getInstance())*

2.  Start session *(ClientSession.startSession(username, password))*

3.  Search and retrieve data *(ApplicationService.search(...))*

4.  Terminate session *(ClientSession.terminateSession())*

**Note:** Steps 2 and 4 are required only for the secured APIs.

When the client application invokes into the generated API to start the
session, the user also passes security credentials (username and the
password) to be authenticated against. Upon successful authentication, a
client session is initiated (which will be available to all the threads
trying to access the application service from the same JVM) and will
remain active till the user purposefully terminates it by invoking into
API's terminate session method call. After successful initialization of
the session, each method call to the client API
(ApplicationServiceClientImpl) obtains the client security session
information from client session before sending the request to the server
(ApplicationServiceServerImpl). Since the client session information is
stored once per JVM, the intercepting class
(ApplicationServiceClientImpl) can obtain that information unless it is
cleared by the user.

On the server side, ApplicationServiceServerImpl intercepts the method
call to the ApplicationService and retrieves the security credentials
from the request parameters. The security credentials are then stored in
a thread level variable so that underlying layers can access it to
determine security information without modifying the method signatures
of each and every method.

## Known limitations of current implementation

In SDK 3.2, the security was implemented in all the three different
interfaces available to access the data. i.e. 1) Web interface 2)
Webservices interface and 3) Java API interface. First two interfaces do
not have any known problems with multiple users trying to access the
data at the same time from the same machine. However, the Java API
interface does not allow more than one user to use the system at the
same time using the same security credentials. SDK generated Java client
API stores the security credentials of the user who accessed the system
last. In the event of multiple users trying to access the Java client
API at the same time (this will be the case if the generated Java client
is being used inside the web application), the system propagates invalid
information from the client to the server (i.e. information of the last
user of the API and not the current user).

# Proposed Changes in SDK 3.2 Security for caGRID Compatibility

## Known Requirements

1.  Allow users to specify the security policy implementation (Global or
    Per thread)

2.  Allow concurrent users to access the secured system generated by SDK
    on caGRID

3.  Keep the user interface backwards compatible with SDK 3.1/3.2

## Possible approaches to implement the requirements

In order for Java beans to connect to the server when user demands for
an associated object, caCORE SDK's Java Beans has to know 1)
ApplicationService from where it came (or from where to get the
associated objects) and 2) User's security credentials (ClientSession)
which he/she is using to retrieve the data from the server. There are
many different ways the Java Bean can learn this information that
includes

1.  Using Singleton design pattern for ClientSession and
    ApplicationService objects

2.  Using JNDI for ClientSession and ApplicationService storage

3.  Store ClientSession and ApplicationService reference inside the Java
    Bean by using dynamic proxies

4.  Using singleton per thread (ThreadLocal) for ClientSession and
    ApplicationService

First two approaches will limit only one user per JVM i.e. only one user
can access secured application at a time. caCORE SDK's current
implementation is based on the approach 1 as mentioned in the previous
section. Approach 1 and approach 2 are virtually the same approach.

On the other hand, the last two approaches allow concurrent users to
access the secured system at the same time. Sections below describe
implementation details for the approach 3 and 4.

## Dynamic Proxies based implementation

An alternate way to implement the security in SDK generated system would
be that the ApplicationService would remember the user who is been using
the service to obtain the data from the server. In order to implement
such a solution, one can use an option of Dynamic Proxies. CGLIB is a
publicly available open source API that allows the user to create a
proxy subclass for any concrete object, which is not possible with JDK
dynamic proxies. By using CGLIB for implementation, one can ensure that
the security information is stored inside the proxy representation of
the Java beans being fetched from the server. This stored information
can be utilized to fetch associated objects along with proper security
credentials. However, implementing this solution would break the
backwards compatibility requirement so this solution is not feasible for
the current release and can be considered as candidate for the future
release.

## TheadLocal based implementation

ThreadLocal based implementation will allow the system to store the
user's security credentials in the storage space specific to the current
thread under execution. As shown in the sequence diagram below, one
needs to store the information in the ThreadLocal variable instead of a
local singleton object in order to implement the solution.

![](media/image6.wmf){width="7.248611111111111in"
height="5.554861111111111in"}

[]{#__RefHeading___Toc160512114 .anchor}Figure 2: Client Application
using a Secured API generated with caCORE SDK

### CORESystem.properties

In order to allow the users to specify the security policy
implementation externally, configuration information is required to be
stored in an external file. CORESystem.properties file holds some of the
key properties required by the system at the runtime. An additional
property should be defined in this file to indicate the security policy.
Suggested values for the property is as below

SECURITY_POLICY=1 (Thread level)

SECURITY_POLICY=2 (Global level)

Thread level security means that the user information will be stored per
user thread. Global level security means that the user information will
be stored per JVM.

**Note:**

1.  If the user decides to use a custom classloader to load the SDK
    generated system then the Global level security will mean "User per
    classloader"

2.  CORESystem.properties file will be loaded only once when
    ClientSession class is being accessed for the first time by JVM i.e
    when the class is being loaded.

### ClientSession

ClientSession class is the main class that orchestrates the security in
coordination with ApplicationServiceClientImpl class.
ApplicationServiceClientImpl class accesses getInstance() method of the
ClientSession to obtain the current client session. Based on the
security policy (Thread or Global), the ClientSession class should
return appropriate instance of ClientSession to be used. On the other
hand, the ClientSession class should configure itself by reading the
CORESystem.properties file to determine security level. In case if the
user has specified wrong security level or user has not specified any
security level then in that case the ClientSession should default to the
Global security level.

If the Global security level is been defined then in that case, the user
should always get back the same instance of ClientSession object from
any thread it invokes from. This can be achieved by using a Singleton
design pattern on ClientSession object. Current implementation of
ClientSession works on the Global security level without using the name
"Global".

If Thread based security level is been defined by the user then in that
case the ClientSession object should be stored in the stack of current
thread under execution. This functionality can be achieved by using a
ThreadLocal feature of JDK.

### Known limitations 

The suggested approach makes sure that the multiple users can access the
ApplicationService at the same time from different thread which
satisfies the need of caGRID and also keeps the interface of the API to
be backwards compatible. However, while doing so, the burden of closing
the ClientSession will be on the user of the generated client API i.e.
caGRID. If for some reason the user (client program) do not terminate
the ClientSession then it will be up to the implementation of the
container (which is creating threads in which user is executing the
ApplicationService) to clean up the ThreadLocal variable from the stack
of the current executing thread before returning that thread to the
pool.

### Additional steps required for caGRID integration

The CORESystem.properties file is bundled together with the SDK
generated client JAR file. In order to configure the Thread level
security, the CORESystem.properties file needs to be changed. Following
are the steps to change the property file

1.  Extract the client JAR file in temporary folder

2.  Open CORESystem.properties file

3.  If SECURITY_POLICY property exist and it has value anything other
    than "1" (Thread level) then change it to "1"

4.  If SECURITY_POLICY property do not exist then add the property with
    value of "1" (Thread level)

5.  Close the property file

6.  Repackage the client JAR fileFiles to be Modified

### List of Files to be Modified

  -------------------------------- ----------------------- -----------------------------
  **File Location**                **File Name**           **Purpose**

  gov.nih.nci.system.comm.client   ClientSession.java      Implement the suggested
                                                           changes from previous section

  conf                             CORESystem.properties   Incorporate SECURITY_POLICY
                                                           property
  -------------------------------- ----------------------- -----------------------------

# Security in Thick Client

SDK generated remote client has a limitation with the login mechanism.
In the caGRID environment, when the grid service wants to make a secured
call to the SDK generated remote service, the grid service invokes into
the ClientSession.startSession() method which in turn sends username and
password as security credentials to the SDK generated server
application. As the grid user's login information is a grid proxy (which
is a publicly available information), the security login is mimicked and
can allow external users to login using a spoof grid proxy. In order to
resolve the problem, the SDK generated application will have to be
deployed as part of the grid service so that the security credentials do
not travel across the unsecured environment like SDK generated server
application.

## Known Requirements

1.  Allow users to use security in the Thick client generated by caCORE
    SDK

2.  Keep the user interface backwards compatible with SDK 3.1/3.2

## Current Implementation of Thick Client

![](media/image7.wmf){width="6.7125in" height="2.4451388888888888in"}

[]{#__RefHeading___Toc160512115 .anchor}Figure 3: Thick Client
Communication in caCORE SDK

In the current implementation, when the client application demands for
ApplicationService instance, a local instance (ApplicationServiceImpl)
is returned to the client instead of remote instance
(ApplicationServiceClientImpl). ApplicationServiceImpl class is a child
class of ApplicationService which implements all the abstract methods
for search operations.

## Limitation of Current Implementation

As mentioned in the previous section, the client performs a login on the
ClientSession which in turn invokes into the
ApplicationServiceServerImpl and creates a new UserSession on the SDK
generated server application. As the thick client is embedded within the
user application, it does not have ApplicationServiceServerImpl,
ApplicationServiceClientImpl and ClientSession classes. As a result, the
client application is not able to log in to the application and a
secured operation cannot be performed.

## Proposed Approach

![](media/image8.wmf){width="7.245138888888889in"
height="5.179166666666666in"}

[]{#__RefHeading___Toc160512116 .anchor}Figure 4: Thick Client
Application using a Secured API generated with caCORE SDK

The sequence diagram shown above describes the behavior of the Thick
client API generated by caCORE SDK. The sequence diagram looks identical
to the sequence diagram for the remote client. In the remote client when
the ApplicationServiceClientImpl wanted to send information across to
the ApplicationServiceServerImpl, Spring framework was being used to
leveraged to handle remoting component. In the proposed design, instead
of using the remoting component, the ApplicationServiceClientImpl class
will be able to get a direct reference to the
ApplicationServiceServerImpl from the local classpath. Once the remote
communication component is bridged locally, rest of the application will
work in identical manor to the remote client server communication.

### CORESystem.properties

In order to allow the users to specify the client implementation
externally, configuration information is required to be stored in an
external file. CORESystem.properties file holds some of the key
properties required by the system at the runtime. An additional property
should be defined in this file to indicate the client implementation.
Suggested values for the property is as below

CLIENT_TYPE=1 (Remote Client)

CLIENT_TYPE=2 (Thick Client)

## Limitations of Proposed Approach

The proposed implementation keeps all the communication layers in the
system to maintain the existing workflow, which is unnecessary. Since
the communication layers do not add any additional overhead other than
passing information to the next layer in the sequence, proposed
approach's limitation can be ignored.

### Additional steps required for caGRID integration

When the user of the grid service is trying to create the grid service,
he should be prompted for remote client vs thick client. If the user is
using the thick client then following items should be considered for
grid service deployment

1.  Thick client required additional JAR files which are kept under the
    lib directory of thick client generated

2.  If user has specified JNDI datasource in the database configuration
    with Hibernate then users should be prompted for a) datasource
    configuration with container and 2) putting proper driver file in
    the container's shared library.

## List of Files to be modified

  --------------------------------------- ----------------------------------- ------------------------------
  **File Location**                       **File Name**                       **Purpose**

  gov.nih.nci.system.applicationService   ApplicationServiceProvider.java     Always return
                                                                              ApplicationServiceClientImpl
                                                                              class for ApplicationService
                                                                              for thick client

  gov.nih.nci.system.comm.client          ClientSession.java                  Get reference to local vs
                                                                              remote
                                                                              ApplicationServiceServerImpl

                                          ApplicationServiceClientImpl.java   Get reference to local vs
                                                                              remote
                                                                              ApplicationServiceServerImpl

  gov.nih.nci.system.comm.server          ApplicationServiceServerImpl.java   Always get instance of
                                                                              ApplicationServiceImpl.java

  conf                                    CORESystem.properties               Incorporate THICK_CLIENT
                                                                              property
  --------------------------------------- ----------------------------------- ------------------------------

# CSM Enhancements for caGRID Integration

The CSM caGrid Integration currently uses a beta release of CSM v3.2.
Also they do not leverage the new capabilities provided by CSM v3.2 like
the new integration and installation procedure or the enhanced exception
handling capabilities. However to integrate the latest 3.2, minor
modification would be needed to support overriding of the manager (as
done by the caGrid team) using the new installation procedure

The following pertain to requirements deemed necessary for upgrading the
CSM / SDK as well as the CSM / caGrid Integration to use new
functionalities provided in CSM v3.2

## Upgrading the CSM/caGRID Integration Code Base

Currently the CSM / caGrid Integration uses a beta version of the CSM
v3.2 release. There have been many new features added to the CSM v3.2
after this beta version. These new features cannot be leveraged by the
caGrid client. Hence in order to provide these the CSM / caGrid
integration would be updated to use the latest version of CSM.

The CSMGridAuthorizationManager class from the caGrid Authz project
would need to be upgraded to implement the new Authentication and
Authorization Manager of CSM v3.2. In order to do so, the CSM API
library jars would be upgraded along with the necessary supporting jars.
However to be in sync, even the caCORE SDK project would be upgraded to
use the exact version of CSM APIs.

## Integrating the new Installation process for CSM in SDK generated system 

Currently the in a CSM enabled SDK generated system users need to
configure CSM externally after they have generated the system. This is
cumbersome and error prone. Also it requires users to read a separate
guide for CSM apart from the SDK Guide.

In order to facilitate ease of installation of a CSM enabled SDK
generated system we need to leverage the new features provided by the
underlying CSM v3.2. For this the following changes will be made to an
SDK generated system.

1.  SDK's deploy.properties file will now have additional parameters for
    the user to specify the database connection parameters for the CSM
    Authorization Schema. Following are the new entries

    a.  csm.database.url -- This is the jdbc url for the CSM
        Authorization Schema

    b.  csm.database.username -- This is the user name to used to
        connect to the database

    c.  csm.database.password -- This is the password to used along with
        the user name for connecting to the database

    d.  csm.database.driver -- This is the database driver used for
        connecting to the database

    e.  csm.hibernate.dialect -- This is the hibernate dialect class
        which needs to be used to communicate with the database

2.  SDK will now have a new ant task which will create a hibernate
    configuration file which points to the CSM Authorization Schema if
    the user's have enabled CSM Security. This task will create a new
    hibernate cfg file using the CSM application context name provided
    in the deploy.properties from a pre-created template. The file name
    will follow the following convention for the CSM APIs to recognize
    it and use it for connecting to the database

    a.  \<\<Application Context Name\>\>.csm.new.hibernate.cfg.xml

> Also this task will replace the place holders for the database
> parameters with the one supplied above in step 1. This file will then
> be placed in the classpath in the WEB-INF/classes folder of the SDK
> generated server web application (war file). The CSM APIs will
> recognize the file and use it directly to connect to the Authorization
> Database.
>
> Also this task will replace the place holders for the database
> parameters with the one supplied above in step 1.

3.  This ant task will also create an Application Security Config with
    an entry for the application using the Application Context Name
    provided. This will be a blank entry which will later be used by the
    caGrid Integration to supply their implementation of the CSM
    Authorization Manager. This file will also be placed in the
    classpath in the WEB-INF/classes folder of the SDK generated server
    web application (war file).

4.  This eliminates the need for the users to

    a.  Make an entry in the properties file to point to the Application
        Security Config file

    b.  To create the Application Security Config file itself with the
        entry for the application and pointer to the hibernate config
        file.

    c.  To create the external hibernate config file to point to the
        database.

> **Note:** This process just eliminates the need to configure
> Authorization externally. Users still need to provide a JAAS entry for
> the purpose of CSM Authentication to work.

## Integrating the new Installation process for CSM in the CSM / caGrid Integration

With the above mentioned CSM SDK Integration in placed we can now
leverage the CSM's easy installation steps while creating a grid node
for a CSM SDK generated system. This eliminates the need for configuring
an external Application Security Config file as mentioned above in last
step.

However the caGrid Integration their own implementation of the
Authorization Manager which they specify using the Application. They
have overridden certain methods of the CSM's AuthorizationManager to
invoke GridGrouper for obtaining the user's group and it purpose of
Authorization.

So if we want to provide easier way of configuring the CSM enabled SDK
generated web application, then we need to modify CSM to allow
overriding of both the Authentication and Authorization Managers in the
new configuration.

Following are the changes which would be made to the CSM APIs

1.  CSM Security Service Provider will be modified to accept the
    Application Security Config file from class path as well.

2.  It will try to read the Authorization Class implementation for the
    Application from the Application Security Config File. If it finds
    it, it would use that implementation else it would just use the
    default implementation provided by CSM.

3.  It would then proceed to load the hibernate configuration from the
    classpath as per the new installation procedure happening in CSM
    v3.2

The caGrid Integration will need to perform the following steps to over
ride the default implementation of the CSM make an entry in Application
Security Config file to provide their implementation of the CSM's
AuthorizationManager Class.

1.  It would need to explode the SDK's generated war file and open the
    Application Security Config file from the WEB-INF/classes folder.

2.  It would need to make an entry in this for the
    CSMGridAuthorizationManager as shown below

> \<security-config\>
>
> \<upt-context-name\>
>
> \</upt-context-name\>
>
> \<application-list\>
>
> \<application\>
>
> \<context-name\>
>
> ABC_APP
>
> \</context-name\>
>
> \<authentication\>
>
> \<authentication-provider-class\>
>
> \</authentication-provider-class\>
>
> \<lockout-time\>
>
> \</lockout-time\>
>
> \<allowed-login-time\>
>
> \</allowed-login-time\>
>
> \<allowed-attempts\>
>
> \</allowed-attempts\>
>
> \</authentication\>
>
> \<authorization\>
>
> \<authorization-provider-class\>
>
> [gov.nih.nci.cagrid.authorization.impl.CSMGridAuthorizationManager]{.mark}
>
> \</authorization-provider-class\>
>
> \<hibernate-config-file\>
>
> \</hibernate-config-file\>
>
> \</authorization\>
>
> \</application\>
>
> \</application-list\>
>
> \</security-config\>

3.  Repackage the war with the above changed file and deploy the same.
    Now whenever the application invokes CSM it would use the Grid
    Implementation of the Authorization Manager as desired.

## Configurable Authentication and Authorization for an SDK generated System

Currently whenever you enable security in an SDK generated system it
turn on both the Authentication as well Authorization services. This
requires the user to first provide credentials to be authenticated and
then only a session is initiated for him. Once a session is established
the user can perform multiple query requests over this session. The user
token associated with the session is used to determine whether the user
has permissions to perform that particular operation or access that
particular resource.

However in case of a grid node the authentication is performed by the
under lying grid security framework (GAARDS). Hence whenever the user is
trying to access data via the SDK generated client or thick client, he
is already validated for his authenticity using his grid credentials.
Currently both CSM and CSM enabled SDK generated system do not posses
the capabilities to validate the grid credentials due to the following
reasons:

1.  The are not part of the grid trust fabric as the result they cannot
    validate the grid proxy certificate

2.  The user's private key is not available for signing. As a result the
    authentication mechanism cannot be guaranteed, as it would be based
    on user's public information like his grid proxy certificate or grid
    identity.

To overcome the need for Authentication, currently the caGrid
integration team had overridden the authentication service to just
validate the user using his grid identity and the service URL as user
name and password. Again this was not optimum as both of these
credentials are public information and a informed user can easily
provide these from other clients for the same SDK generated system and
obtain entry into the system.

So to over come these shortcomings the following changes are proposed.

1.  The caGrid Introduce tool will now use an SDK generated thick client
    in order to generate a data service node.

2.  The CSM integration in SDK will be made configurable to allow either
    of the security services to be used. So based on the configuration
    settings user can select either authentication or authorization
    services or both.

3.  When the authentication service is turned off, CSM will generate a
    user session token without authenticating the user.

4.  All these configuration will be made part of an external
    configuration file (CORESystem.properties) to allow modifications
    without need to regenerate the code.

## Changes to the caGrid Tools and Services

Based on the changes mentioned above, the caGrid Team would be needed to
perform the following changes:

1.  Upgrading the GridCSMAuthorizationManager to the latest CSM v3.2
    Interfaces and also to remove the current Authentication Mechanism
    using the grid identity and the service URL

2.  Repacking of the SDK generated thick client / server component to
    override CSM's default AuthorizationManager with
    GridCSMAuthorizationManager in the ApplicationSecurityConfig file