The CAS service can be configured with a description of the VO the CAS service serves and the maximum lifetime of the assertions it can issue. Also, the service needs to be configured with information about the back end database it uses. Any database with a JDBC driver and reasonable SQL support can be used. That said, PostgreSQL was used for development and testing and we strongly recommend that you use it. The CAS database schema to be used with PostgreSQL has been provided in $GLOBUS_LOCATION/etc/globus_cas_service/casDbSchema/cas_pgsql_database_schema.sql.

Other than that, the security settings of the service can be modified in the security descriptor associated with the CAS service. It allows for configuring the credentials that will be used by the service, the type of authentication and message protection required as well as the authorization mechanism. By default, the following security configuration is installed:

	Note
	Changing required authentication and authorization methods will require matching changes to the clients that contact this service.

	Important
	If the service is configured to use GSI Secure Transport, then container credentials are used for the handshake, irrespective of whether service level credentials are specified.

By default, the CAS service is not loaded at start up. To change this behavior, uncomment the loadOnStartup property set in $GLOBUS_LOCATION/etc/globus_cas_service/server-config.wsdd as shown below.

Once the loadOnStartup property is uncommented, the following happens at start up:

<service name="CASService" provider="Handler" use="literal" 
      
      style="document">
      
      <!-- Uncomment if the service needs to be initialized at startup -->
      
      <parameter name="loadOnStartup" value="true"/>
      
      <parameter name="allowedMethodsClass" 
      
      value="org.globus.cas.CASPortType"/>
      
      .
      
      .
      
      .
      
      </service>

To change the maximum assertion lifetime and VO description, set the parameters maxAssertionLifetime and voDescription in $GLOBUS_LOCATION/etc/globus_cas_service/jndi-config.xml to the desired values.

To alter the configuration of the database back end edit the databaseConfiguration section of $GLOBUS_LOCATION/etc/globus_cas_service/jndi-config.xml as follows:

To alter the security descriptor configuration refer to Security Descriptors. The file to be changed is $GLOBUS_LOCATION/etc/globus_cas_service/security-config.xml.

CAS is used to administer access rights to files and directories and the GridFTP server can be configured to enforce those rights.

For detailed information about configuring CAS for use with a GridFTP server, see http://www.globus.org/toolkit/docs/4.0/security/cas/WS_AA_CAS_HOWTO_Setup_GridFTP.html.

With a default GT 4.0.1 installation, CAS is automatically registered with the default WS MDS Index Service running in the same container for monitoring and discovery purposes.

	Note
	If you are using GT 4.0.0, we strongly recommend upgrading to 4.0.1 to take advantage of this capability.

However, if must use GT 4.0.0, or if this registration was turned off and you want to turn it back on, this is how it is configured:

There is a jndi resource defined in $GLOBUS_LOCATION/etc/globus_cas_service/jndi-config.xml as follows :

 
    <resource name="mdsConfiguration" 
    
    type="org.globus.wsrf.impl.servicegroup.client.MDSConfiguration">
    <resourceParams>
    <parameter> 
    <name>reg</name>
    <value>true</value>
    </parameter>
    <parameter> 
    <name>factory</name>
    <value>org.globus.wsrf.jndi.BeanFactory</value>
    </parameter>
    </resourceParams>
    </resource>
  

To configure the automatic registration of CAS to the default WS MDS Index Service, change the value of the parameter <reg> as follows:

      <Content xsi:type="agg:AggregatorContent"
      xmlns:agg="http://mds.globus.org/aggregator/types">
      
      <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
      
      <agg:GetResourcePropertyPollType
      xmlns:cas="http://www.globus.org/07/2004/cas">
      <!-- Specifies that the index should refresh information
      every 8 hours (28800000ms) -->
      <agg:PollIntervalMillis>28800000</agg:PollIntervalMillis>
      
      <!-- specifies that all Resource Properties should be
      collected from the RFT factory -->
      
      <agg:ResourcePropertyName>cas:VoDescription</agg:ResourcePropertyName>
      
      </agg:GetResourcePropertyPollType>
      </agg:AggregatorConfig> 
      <agg:AggregatorData/>
      </Content>
    

If a third party needs to register an CAS service manually, see Registering with mds-servicegroup-add in the WS MDS Aggregator Framework documentation.

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.

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.

casadmin$ createdb casDatabase  

casadmin$ psql -U casadmin -d casDatabase -f  \

$GLOBUS_LOCATION/etc/globus_cas_service/casDbSchema/cas_pgsql_database_schema.sql

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

dbDriver=database driver name

dbConnectionURL=database connection URL

dbUserName=Username to access database

dbPassword=Password for the above username

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.

These tests can be set up so as to be able to test multiple user scenarios or can be configured to run as just a single identity. A file with configuration information needs to be setup for the tests to pick up parameters.

There are two test targets in the service tests. The first set of tests should be run with a set of credentials, where the user is given super user permissions on the CAS server. These tests also set the permissions for another user to run the second set of tests, without super user permissions. The first user DN is configured as property "user1SubjectDN" and the second user is configured as property "user2SubjectDN".

The test can be simplified to use same credentials for both tests. In such a scenario, the DN of credential used to run the tests should be configured as "user1SubjectDN" and the property "user2SubjectDN" can be set to any string.

All the configuration information for the test needs to be configured in the etc/globus_cas_unit_test/casTestProperties file. The database section of the properties file needs to be configured as described here. In addition the following properties need to be configured to run the tests:

Steps for testing:

	Important
	The database bootstrap needs to be done again for the server to be ready to receive client requests.

Since at the time of booting up the CAS server only the user group that has super user permissions on the CAS server is created, Alice will want to create another user group to which new users can be added and to which permissions on newly enrolled CAS entities may be given. This also eases the process of giving the same rights to many users. Given that there are two types of roles in the community she might want to create two groups, analysts and scientists.

Also, all permissions on the newly created group will be given to users of a particular user group. For example, Alice may want all users of the user group analysts to be able to manipulate the group.

To create a new user group Alice uses the cas-group-admin client. It requires a name for the new group being created, say analysts.

alice%  cas-group-admin user create analysts analysts

This will create a user group analysts and give all users in that group the permission to manage the group (i.e add users, remove users and so on). She can similarly create a group called scientists.

Prior to adding Bob and Carol to the CAS server, Alice needs to ensure that the trust anchors for both have been added. If they share the trust anchor with Alice then this step can be skipped, since at bootstrap Alice's trust anchor would have been added to the database.

In our example Alice and Carol share a trust anchor different from Bob's. Therefore, Alice needs to add Bob's trust anchor by using the cas-enroll client with the trustAnchor option. She needs to provide details about the trust anchor such as the authentication method and authentication data used.

alice%  cas-enroll trustAnchor analysts AbcTrust X509 "/C=US/O=some/CN=ABC CA"

The above will enroll a trust anchor with nickname AbcTrust that uses X509 as its authentication method and has the DN specified in the command. The members of the analysts user group are given all rights on this object. This implies that any user who has this trust anchor is assumed to present credentials signed by this trust anchor.

Now Alice can add Bob and Carol as users using the cas-enroll command with the user option. She needs to provide the user's subject DN and a reference to the trust anchor used by the user. As with any entity added to the CAS server, the admin needs to choose a user group whose members will have all permissions on that entity. In this example, Alice would like the members of the user group suUser to be able to manipulate the user entity Bob.

alice% cas-enroll user suUser bob "/O=Our Community/CN=Bob Foo" AbcTrust

Alice uses a similar command to add Carol to the CAS database.

The CAS server allows rights to be assigned only to user groups and not to individual users. Hence, before Alice can assign rights to Bob or Carol, she needs to add them to some user group. She does this by using the cas-group-add-entry client with the user option to indicate she is adding to a user group. This client requires the group name and the nickname of the user who needs to be added. To add Bob to the analysts group, the command would be:

alice% cas-group-add-entry user analysts bob

If a user group scientists was created, Carol could similarly be added as a member.

Alice now has the community users in the database. The next step is to add some resources. Because the community currently has the FTP server foo.bar.edu available to it she will add it to the CAS database.

Each resource or object in the CAS server has a namespace associated with it that defines certain features. For example, it can define the comparison algorithm that is to be used when the object's name is compared. It may also define the base URL that should be prefixed to objects that belong to this namespace. In this case, Alice chooses to use the FTPDirectoryTree namespace that is added to the CAS server at startup. She uses the cas-enroll client with the object option to add the FTP server to the CAS database:

alice% cas-enroll object suGroup ftp://foo.bar.edu/* FTPDirectoryTree

This command adds the FTP server as an object and gives all members of the suGroup rights to manipulate the object.

To be able to grant/revoke access on an individual directory, add an object for the directory. For example, if Alice would like to be able to manipulate the data directory on the server as a separate entity, the following command will add an object for that.

alice% cas-enroll object suGroup ftp://foo.bar.edu/data/* FTPDirectoryTree

Alice suspects that the community will end up with more directories containing data on other servers that will have polices identical with the ones on the /data directory on foo.bar.edu. To manage this she is going to create an object group called data and assign foo.bar.edu/data to this group. This will allow her to grant rights on this group and easily add other directories to this group later.

To create a group called data, she uses the cas-group-admin client with the group and create options:

alice% cas-group-admin object create suGroup data

This creates an object group called data and the members of suGroup get all rights on this group and hence should be able to add/remove members, grant rights to add/delete from this group to others and also delete this group.

Alice now can add foo.bar.edu/data to the data group. She can do this by using the cas-group-add-entry with the object option. To add the above object, ftp://foo.bar.edu/data/* in the namespace FooFTPNamespace, to the object group data Alice uses the following command:

alice% cas-group-add-entry object data object FooFTPNamespace ftp://foo.bar.edu/data/*

In the above command:

Alice now needs to add information about the kinds of rights that can be granted for these objects. These are stored as service types and relevant actions are mapped to these service types.

In this scenario, the kind of service types that Alice should add would be file, directory and so on. To do so the cas-enroll client with the serviceType option may be used. To add a service type called file and give members of suGroup all rights on this service type Alice uses the following command.

alice% cas-enroll serviceType suGroup file

The relevant action mappings to the above mentioned service types would be read, write and so on. Alice needs to add these mappings to the database so that she can grant rights that allow a user to have file/read or file/write permissions on some object.

To add action mappings to a service type, she uses the cas-action client with the add option. The following command adds a mapping of action read to service type file.

alice% cas-action add file add

Similarly, she can add other mappings, like write, to this service type.

Alice now has resources in the object group data and users in the user groups analysts and scientists. She now wants to grant permissions on the data group to the analysts and scientists, namely read permissions to the analysts and read and write permissions to the scientists.

To grant permissions Alice needs to use the cas-rights-admin with the grant option. To give read permissions to the analysts group Alice runs:

alice% cas-rights-admin grant analysts objectGroup data serviceAction file read

She similarly grants rights to scientists group.

If the CAS service fails with following error:

 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException

 faultSubcode:

 faultString: org.apache.commons.dbcp.DbcpException: Connection

refused. Check t hat the hostname and port are correct and that the

postmaster is accepting TCP/I P connections.

The following are some common problems that may cause clients or servers to report that credentials are invalid: