The CAS service is deployed as a part of a standard toolkit installation. Please refer to the Installing GT 4.1.3 for details. Other than the steps described in the above guide, the following are needed to deploy the CAS service.

1. Obtaining credentials for the CAS service

The CAS service can run with its own service specific credentials. Instructions for obtaining service credentials may be found here.

The standard administrator clients that come with the distribution by default use identity authorization to authorize the service they are running against (and expect that the CAS service has credentials that have the FQDN of the host the server is running on and the service name "cas" as part of DN). Command line options can be used to specify the identity of the CAS service, if the default identity is not used. The command in the above mentioned web page may be altered as follows to get credentials for the CAS server:

casadmin$ grid-cert-request -service cas -host FQDN

The certificate and private key are typically placed in /etc/grid-security/cas-cert.pem and /etc/grid-security/cas-key.pem, respectively. In this document the locations of certificate and key files are referred to as CAS_CERT_FILE and CAS_KEY_FILE, respectively. The subject name in these credentials is expected by CAS clients by default.

2. Database installation and configuration

CAS uses a back end database to store all user data. This section briefly describes the installation of such a database and the creation of the database using the schema required by the CAS back end.

2.1. Installing the database

While any database with a JDBC driver and support for a reasonable set of SQL may be used, Derby has been used for development and testing. The driver for the same is included in the distribution. A default Derby database is created for CAS during installation and the CAS server uses the database in the embedded mode. One set of CAS tests also use the database in the embedded mode and another set uses in the network mode.

	Note
	Any JDBC compliant database might be used as backend. If a different database is used, the corresponding driver should be added to $GLOBUS_LOCATION/lib.

2.2. Creating the CAS database

By default a Derby database is created during deploy time at $GLOBUS_LOCATION/var. But schema for using PostGres or MySQL as backend is provided at $GLOBUS_LOCATION/etc/globus_cas_service/casDbSchema/cas_pgsql_database_schema.sql or $GLOBUS_LOCATION/etc/globus_cas_service/casDbSchema/cas_mysql_database_schema.sql. Please refer to PostGres or MySQL documentation for steps involved in creating the database.

	Note
	This documentation assumes the database name to be `casDatabase`

2.3. Bootstrapping the CAS database

The CAS database needs to be initialized with data specific to CAS and information about a super user to allow bootstrapping of CAS operations. The command line script cas-server-bootstrap can be used to achieve this.

cas-server-bootstrap [<options>] -d <dbPropFile> [ -implicit | -b <bootstrapFile> ]

Table 1. Command line options

`-help`	Prints the help message.
`-debug`	Runs the script with debug trace.
`-d` `dbPropertiesFile`	File name with database properties as follows: dbDriver=`database driver name` dbConnectionURL=`database connection URL` dbUserName=`Username to access database` dbPassword=`Password for the above username`
`-b bootstrapFile`	This option populates the database with super user data and points to a file with data to use for bootstrapping the database. A template file for this can be found at `$GLOBUS_LOCATION/share/globus_cas_service/bootstrapTemplate` and a sample file can be found at `$GLOBUS_LOCATION/share/globus_cas_service/bootstrapSample`.
`-implicit`	Populates the database with: a) CAS server implicit data—this adds the CAS server itself as a CAS object and implicit service/actions like enrolling users, objects and so on; and b) service/action and namespace relevant to FTP like read, write and so on.

Sample bootstrap command:

To bootstrap the CAS database with both implicit and user data the following command can be used. Prior to running the command, the following files need to be created with appropriate values filled in. The values shown here are for default Derby database set up. If using any other database configuration, please fill in or uncomment corresponding values as appropriate.

$GLOBUS_LOCATION/share/globus_cas_service/casDbProperties

# Database driver to use
dbDriver=org.apache.derby.jdbc.EmbeddedDriver
# Connection URL to database
dbConnectionURL=jdbc:derby:casDatabase
# Database user name
dbUsername=casAdmin
# Database password
dbPassword=foobar

$GLOBUS_LOCATION/share/globus_cas_service/bootstrapProperties. Copy the template file $GLOBUS_LOCATION/share/globus_cas_service/bootstrapTemplate as $GLOBUS_LOCATION/share/globus_cas_service/bootstrapProperties and fill in the values as described below. Refer $GLOBUS_LOCATION/share/globus_cas_service/bootstrapSample for a sample.

# This file is used to populate the backend CAS database with a super user.
# Nick name for trust anchor for super user
ta-name=defaultTrustAnchor
# Trust Anchor authentication method, typically X509 Certificates
ta-authMethod=X509
# Trust Anchor authentication data, typically X509 DN
ta-authData=/C=US/O=Globus/CN=Default CA
# Super user nickname
user-name=superUser
# Super user subject name, typically DN
user-subject=/O=Grid/O=Globus/OU=something/CN=suUser
# Super user group name
userGroupname=superUserGroup

Command to run:

casadmin$ cd $GLOBUS_LOCATION

casadmin$ bin/cas-server-bootstrap \

 -d share/globus_cas_service/casDbProperties \

-implicit -b \ share/globus_cas_service/bootstrapProperties

Once the database has been created the CAS service needs to be configured to use it as described here.

3. Deploying into Tomcat

CAS has been tested to work without any additional setup when deployed into Tomcat. Please follow these basic instructions to deploy GT4 services into Tomcat. Note that the Java WS Core module needs to be built and configured as described in the previous sections.

Prev		Next
Configuring	Home	Testing