server start up configuration
a description of the VO the CAS service serves
the maximum lifetime of the assertions it can issue
information about the back end database it uses. Any database with a JDBC driver and reasonable SQL support can be used. The schema that works with Derby database, MySQL and PostGres is distributed and can be found at $GLOBUS_LOCATION/etc/globus_cas_service/casDbSchema.
the security settings of the service and 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.

2. Loading the CAS service at start up

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:

The CAS service is loaded.
The database connection pool is initialized.
The service registers itself to the default MDS Index Service.

<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>

3. Configuring the VO Description

To change the VO description, set the parameter voDescription in $GLOBUS_LOCATION/etc/globus_cas_service/jndi-config.xml to the desired values.

4. Configuring the maximum assertion lifetime

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

5. Configuring database backend

To alter the configuration of the database back end edit the databseConfiguration section of $GLOBUS_LOCATION/etc/globus_cas_service/jndi-config.xml as described below. If you are using the default Derby installation, the only parameter to change is the connectionURL to replace GLOBUS_LOCATION with the actual location of your toolkit installation.

Table 1. Database parameters

driver	The JDBC driver to be used
connectionURL	The JDBC connection url to be used when connecting to the database
userName	The user name to connect to the database as
password	The corresponding database password
activeConnections	The maximum number of active connections at any given instance
onExhaustAction	The action to perform when the connection pool is exhausted. If value is 0 then fail, if 1 then block and if 2 then grow the pool (get more connections)
maxWait	The maximum time in milliseconds that the pool will wait for a connection to be returned
idleConnections	The maximum number of idle connections at any given time

6. Configuring security descriptor

By default, the following security configuration is installed:

Credentials are determined by the container level security descriptor. If there is no container level security descriptor or if it does not specify which credentials to use then default credentials are used.
Authentication and message integrity protection is enforced for all methods except queryResourceProperties and getResourceProperty. This means that you may use any of GSI Transport, GSI Secure Message or GSI Secure Conversation when interacting with the CAS service.
The standard authorization framework is not used for authorization. Instead the the service uses the back end database to determine if the call is permitted.

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.

	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.

7. Configuring with a GridFTP Server

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 How to Set up CAS with GridFTP.

8. Configuring CAS to manage policy for web service.

The CAS server can be used to admiminster rights for access to web services. The mapping from CAS objects to the web service resource is shown on this table:

Table 2. Mapping from web services object to CAS object

Object	EPR of WS resource as string. The OGSA-AuthZ specification defines how a EPR can be represented as a string and a utlity for such is provided at `org.globus.wsrf.impl.security.EPRUtil`.
Object namespace	The object namespace is used to get both a comparison algorithm and the basename. For web services policy we need exact comparison and also don't have any base name. An implicit namespace casDefaultNs with the required properties is added to the service.
Service type	The OGSA-AuthZ specification defines a service type to use for web services operation as "http://www.gridforum.org/namespaces/2003/06/ogsa-authorization/saml/action/operation" This is defined as a constant in org.globus.wsrf.impl.security.authorization.SAMLAuthorizationConstants and is added implicitly.
Action	This is the actual operation on the webservice. For example method "add" on Counter Service.

An example scenario is described here.

9. CAS auto-registration with default WS MDS Index Service

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:

true turns on auto-registration; this is the default in GT 4.0.1.
false turns off auto-registration; this is the default in GT 4.0.0.

9.1. Configuring resource properties

By default, the VoDescription resource property (which describes the virtual organization relevant to the CAS Service) is sent to the default Index Service.

You can configure which resource properties are sent in the registration.xml file, $GLOBUS_LOCATION/etc/globus_cas_service/registration.xml. The following is the relevant section of the file:

      <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>

10. Registering CAS manually with default WS MDS Index Service

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

Prev		Next
Building and Installing	Home	Deploying