This document is an overview of the CAS server and its functionality. It is intended to help CAS developers understand the features of the current implementation and throws light on permissions, assertion generation and querying capability in CAS. This document also contains information that is useful when writing clients for the CAS server.

The Toolkit-level documentation GT Release Manuals provide general information such as best practices and coding guidelines used.

2. Before you begin

2.1. Feature summary

Features new in GT 4.1.2:

Support for OGSA-AuthZ Authorization Service interface
Support for managing web services policy.

Other Supported Features

File-level access control for GridFTP
Issuance of SAML authorization decisions

Deprecated Features

None

2.2. Tested platforms

Tested Platforms for CAS

Windows XP
Linux (Red Hat 7.3)

Tested Containers for CAS

Java WS Core container
Tomcat 5.0.30

2.3. Backward compatibility summary

This section is not applicable for development releases.

2.4. Technology dependencies

The CAS service depends on the following GT components:

WS Authentication and Authorization
Java WS Core

The CAS GridFTP authorization module depends on the following GT components:

Pre-WS Authentication and Authorization

The CAS service depends on the following 3rd party software:

OpenSAML

The CAS GridFTP authorization module depends on the following 3rd party software:

libxml

2.5. Security considerations

The database username/password is stored in the service configuration file and the test properties file. Ensure correct permissions to protect the information.

3. Architecture and design overview

The server essentially has users, actions, objects and policies governing the user's access to the objects for the purpose of performing specific actions. To better serve the requirements of a VO, the server allows grouping of users, actions and objects. This also facilitates specifying policies about them. The CAS server can be thought of as the front-end to a database that maintains state about such community permissions. The effect of each CAS request is either to modify this state or query it.

The server has two additional characteristics:

Some query results are signed. Such signed results can be used for authorization at resources and other policy enforcement points that acknowledge such credentials.
The same database is used to maintain information to control authorization decision for the CAS server.

The following topics contain related information:

3.1. CAS Database Overview

The CAS database contains a number of tables to store information about users, resources (objects), actions and policies. This section describes each of those tables and their contents. The tables are categorized into tables used to identify and organize users in the database (trust_anchor, user and user_group), tables used to describe actions (service_type, service_type_action, service_type_action_groups), tables used to describe and organize resources or objects (object, object_namespace and object_group) and tables used to describe policies (policy_statement).

3.1.1. Tables relating to users

There are two categories of people in the CAS database, trust anchors and the users. The users may further be placed in user groups and the granularity of operations on the CAS database with respect to users is a user group.

Table 1. User tables

trust_anchor table	The trust_anchor table describes authorities that can generate credentials. It consists of tuples of {trust_anchor_nickname, authentication_method, authentication_data}. In general, the meaning of one of these tuples is that "database entries that refer to trust_anchor_nickname apply to the authority represented by authentication_data for authentication method authentication_method". The current implementation supports the following values in these fields: an authentication_method value of "x509" and an authentication_data value that is the certification authority's certificate. A trust_anchor_nickname value uniquely identifies an authentication_method and authentication_data across the database. For example, {globus_ca, x509, <contents of the globus CA cert>} associates the name globus_ca with the Globus CA Certificate.
user table	The user table consists of {user_nickname, trust_anchor_nickname, subject_name} tuples, which map raw authentication information into the symbolic names that appear in CAS user specifications. The intent of this tuple is to associate an internal name with a user that authenticates to the CAS service. The current implementation supports a subject_name which is the X509 distinguished name of a user. A subjectDN and trust anchor nickname uniquely identify an entry in the user_table. There is a one to one mapping between a user nickname and the combination of subjectDN and trust anchor nickname. For example, the tuple {user1, globus_ca, "/O=Globus/CN=User1 Name") indicates that the person who can authenticate as "/O=Globus/CN=User1 Name" using the authentication method of the trust anchor globus_ca has the permissions assigned to the user "user1" within the CAS database.
user_group table	This table maintains a list of all user groups in the CAS database.
user_group_entry table	The user_group_entry table consists of {group, user} tuples indicating that the specified user is a member of the group.

3.1.2. Tables to relating to actions

The database includes tables related to action specifications. Different services may define actions that have similar (or identical) names with different meanings and hence an action specification must include a service type in addition to the name of the action. The resource servers that receive CAS policy statements interpret the service types and actions. For example, a GridFTP server may honor policy statements that refer to the "file" service type and ignore policy statements for all other service types. In theory (because all this processing is done by the resource servers and not the CAS server), there's no need for the CAS server to keep track of allowable service types and actions. However, it is done to make it easier for administrators to detect and avoid errors while setting permissions.

The server also supports grouping of these service action mappings. Permissions may be granted to the service action groups or to a single service action.

Table 2. Action tables

service_type table	This table lists all the service types in the database.
service_type_action table	The service_type_action table consists of {service_type, action} tuples indicating that the specified action is valid for the specified service type. For example, a {service_type, action} of {file, read} means that read is a valid action for the service type file. This mapping is represented as "serviceType/action" in the current implementation.
service_action_group	This table lists all the service action group names.
service_action_group_entry	This table contains the following tuple (group, serviceType/action). The tuple indicates that the serviceType/action belongs to group.

3.1.3. Tables related to resources/objects

An object specification refers to an object or group of objects. An "object" may itself refer to either a single physical object (e.g. a file) or a collection of objects (e.g. all files within a directory). A given object is relevant within a defined namespace and the properties of the namespace apply to the object.

Table 3. Resource Tables

namespace_table	This table stores the following tuple (nickname, basename, comparisonAlg) indicating that objects in the namespace referred to by nickname in the CAS database are compared using the comparisonAlg and have a base URL of basename. A namespace uniquely identifies a single physical resource. For example, a namespace (ftpNS1, ftp://sample1.org/, wildcard) indicates that all object names within the realm of this namespace are to be compared using wildcard matching. Each comparison algorithm corresponds to a class in the CAS server code that implements an interface which defines routines for matching objects. The current implementation supports exact match and wildcard matching. Objects are represented as "objectNamespace\|objectName" in the current implementation.
object table	Stores the object name and the namespace that this object is in. For example, (/mydir/*, ftpNS1) implies that this object is within the ftpNs1 namespace, described above. Since this namespace has wild card matching /mydir/foo would match this object. CAS Objects can be either implicit (that is, those that are inherent to CAS) or explicit (that is, objects on other resources about which policies may be stored in the CAS database). While implicit objects may be of many types, external objects are always represented as type "object".
implicit objects	It is sometimes convenient to treat some of the entities defined within the CAS server (such as users and groups) as objects. These implicit objects can be added to object groups and can appear in policy statements. Such policy statements govern access permissions to the CAS database. The types of implicit objects are: A user (a reference to an entry in the user table). This is used when granting permissions such as "may unenroll this user". A user_group (a reference to an entry in the user_group table). This is used to grant permissions such as "may add users to this group". A service_type (a reference to an entry in the service_type table). This is used when granting permissions such as "may add actions to this service type"; An object_group (a reference to an entry in the object_group table). This is used when granting permissions such as "may add objects to this object group". A namespace (reference to an entry in namespace table). This is used when granting permission like "may unenroll this namespace". A trust anchor (reference to an entry in the trust_anchor_table). This is used when granting permissions like "may grant rights on this trust anchor". The CAS server itself. This is used when granting permissions such as "may add new users to the CAS server". This is added at start up to the object_table.
object_group table	This table lists the names of object groups in the database.
object_group_entry table	The object_group_entry table consists of {object_group, objectSpecification, objectSpecDesc} tuples; this tuple indicates that the specified objectSpecification of the type objectSepcDesc is a member of the specified object group. The objectSpecification is an identifier for a object of type objectSpecDesc, i.e. an object, object group, user, user group, service type, namespace or trust anchor.

3.1.4. Tables relating to policy statements

The CAS server keeps track of policy statements, which are composed of three parts: a user specification, which denotes a user or set of users; an action specification, which denotes an operation (e.g., read a file) or a group of operations; and an object specification, which specifies an object or group of objects.

For example, if we were to specify a policy statement as an English sentence, "User1 may read ftp://myhost.edu/myfile", then the user specification would be "User1", the action specification would be "file/read", and the object specification would be ftp://myhost.edu/myfile. In reality, the CAS server maintains this information as entries in database tables and translates it into a policy language when responding to a query.

The policy_statement table consists of (userGroup, actionSpec, actionSpecDesc, objectSpec, objectSpecDesc) tuples corresponding to the policy statements implied by this relationship:

Table 4. Policy Statement Table

userGroup	A reference to an entry in the user_group table.
actionSpec	A reference to an entry in the service_action table or service_action_group table.
actionSpecDesc	Either a "serviceAction" or "serviceActionGroup" describing the actionSpec entry.
objectSpec	A reference to an entry in the object table, object_group_entry table, user table, user_group table, service_type table, namespace table or trust_anchor table.
objectSpecDesc	Either a "object", "objectGroup", "user", "userGroup", "serviceType", "namespace" or "trustAnchor" describing the objectSpec entry.

Each statement implies that users who belong to the userGroup are permitted to perform the service/action or all service/action(s) in the serviceActionGroup on the specified object or all objects in the said object group.

3.2. CAS Permissions

A user (U) is said to have permission to perform service/action S/A on object (O) if there is a statement in the policy_statement table that meets these three conditions:

The user element applies: U appears in the user table and the user element is either:
- a user_group_specification referring to a user_group containing U, or
- the community_specification.
The action element applies:
- the action specification refers to service_type S and the action A.
- the action specification refers to a service_action group that has service type S and action A as a member.
- the action specification is superuser.
The object element applies: it's either:
- An object that "matches" O - that is, the appropriate matching function (based on the namespace that the object belongs to) applied to O and the object_name yields a match, or
- An object group that contains an object that "matches" O.

3.3. CAS Requests

CAS requests can be broadly classified into administrative requests and query requests. Each CAS request requires some set of permissions. These permission are assessed by looking up the authenticated user in the user table (to get the CAS nickname mapped to this user) and using that to check if the policy table has a permission defined for the operation as described in the previous section.

3.4. CAS Administrative Requests

Administrative requests typically modify the database and are used to add or remove CAS table entries.

Enroll or unenroll trust anchors
Enroll or unenroll users
Create or delete namespaces
Create or delete objects
Create or delete service types
Add or remove service type/action mappings
Create or delete user, object or service action groups
Add or remove entries from any of the above
Define groups
Grant or revoke permissions

The above request asserts permissions and performs the operation preserving the database consistency. For example, a policy can be defined (or a right can be granted) only on objects that exist in the CAS database and so on.

Creation of any CAS object (like a trust anchor, namespace, object, user, service type, user group, object group, service_action group) allows the client to choose a user group (irrespective of whether the client belongs to the group or not) to which all permissions on the newly created object is granted. In the case of the operation where the user creates a new user group, if the client chooses to grant all permissions to the newly created user group, then the user is added to the new group.

3.5. CAS Query Requests

Query request are classified into

requests that return assertions that are typically signed and can be used by the client to authorize with some resource.
requests that return information about the current state of the CAS database.

3.6. Assertion requests

The CAS server supports requests to retrieve policy information as signed policy assertions. These assertions can be presented at a resource by the client for authorization purposes. A policy assertion includes a list of policy statements, the distinguished name of the user that the permissions apply to, a validity period (a start and end time corresponding to when the assertion is valid), and is signed by the CAS server. Each of the requests for policy assertions takes a lifetime argument (the desired lifetime of the policy assertion, in seconds) and the following is done to generate them.

The applicable user is identified as described in CAS Permission.
The applicable set of policy statements for the user are identified as described in CAS Permission.
If the set is not empty, a policy assertion is created or else null is returned.
The assertion lifetime is calculated as follows. If the requested lifetime is 0, the server's default lifetime is used, otherwise the minimum of the requested lifetime and the server's maximum lifetime is used.
The list of {service/action, object} permissions, the validity time (start time is the current time, end time is the current time plus the assertion lifetime), and the applicable user's subject name is formed into a assertion.
The assertion is signed and returned to the requester.

In the current implementation the Security Assertion Markup Language (SAML) standard defined by OASIS is used for the requests and responses involved in obtaining a authorization assertions. OpenSAML, an open source implementation of the SAML 1.0 specification, has been used as a utility to generate and process SAML queries and assertions.

The methods for the requests are:

Table 5. Request methods

getMaximalAssertion	This is a self-request that any user in the CAS database may make. The set of policy statements returned is the complete set of the user's permissions, for all services other than the CAS service.
getUserAssertion	In this case, an additional argument specifies the requested user; the set of policy statements is the complete set of that user's permissions for all services other than the CAS service. This request requires cas/query or cas/superuser permission on the cas/server object.
getAssertion	This is a self-request that any user in the CAS database may make. In this case, the list of {service/action, object} permissions is determined as follows: For each requested permission, if there is a policy statement granting the request in the CAS database, then the requested (service/action, object) is added to the returned assertion as a decision statement.

Assertion generation is done based primarily based on the objects. This has implications in the case of maximal assertion and user assertion generation, where all applicable polices are returned. The service restricts polices only based on objects and does not make a distinction on service type. For example, if a non-implicit object has a CAS service type policy on it, it will be returned as a part of the assertion. This might be useful in case some other CAS server is itself being treated as an external resource and the CAS service types are used.

3.7. OGSA-AuthZ Service Interface

The CAS service also exposes a OGSA-AuthZ Service Interface that allows a client to query the server to ascertain rights. The interface allows for a signed SAML Request to be passed as parameter and pull down the rights as a SAML Response. The SAML Request allows for a query with a subject, resource and object to be passed as parameter. The server retrieves rights for the said parameters and returns SAML Authorization Assertions as part of response, if permission exists.

This functionality allows for a pull model, where the a resource can retrieve the rights of a subject from the CAS server. This is an alternative to the push model where the client retrieves assertion about itself and pushes it to the resource. Also, since the interface is a standard authorization service, a callout written to talk to any OGSA AuthZ compliant authorization service can be used.

The resource would need to be configured with information about the CAS Service (like location, CAS credential DN). Following is a list of steps that would be required to retrieve assertions from the CAS server using this interface.

Construct SAML Query containing the subject requesting access, the action and resource for which access is requested.
Construct SAML Request and sign it.
Use CAS's OGSA AuthZ interface and retrieve SAML Response for the request
Verify integrity of the SAML Response
Ensure the CAS server contacted is in a list of trusted servers (based on the DN of the signing entity)
Parse SAML Response to see if server returned an assertion with rights for access.
If no assertion was returned, deny access. If assertion was returned, permit access.

	Note
	Above is just a suggested list of steps. The decision retrieved from assertion might have to be augmented with other authorization schemes prior to permitting access to a resource.

A sample client query-cas-service shows how this interface can be used to retrieve assertions.

4. Public interface

4.1. Semantics and syntax of APIs

4.1.1. Programming Model Overview

The CAS service allows for managing fine grained access policy of resources in a VO. The service has a back end database that stores data about users/resources/actions and the associated rights. It provides an administrative interface for managing the data and a query interface that allows users to retrieve this information. One of the operations in the query interface includes a means to get a signed SAML assertion that the client can present to a resource for authorization purposes.

4.1.2. Component API

Some relevant APIs:

org.globus.cas.CasPortType
org.globus.cas.impl.CasConstants
org.globus.cas.impl.client.CasProxyHelper

Complete API:

4.2. Semantics and syntax of the WSDL

4.2.1. Protocol overview

This component is used to store and retrieve assertions about the rights a user has on some resource to perform some action on a service type. It uses the Security Assertion Markup Language (SAML) to express an authorization query and return an assertion about the objects in the query. It also provides a WSDL interface for administrative tasks such as managing information about users and resources as well as granting and revoking rights on them.

4.2.2. Operations

addUser: Adds a new user.
removeUser: Removes a user.
addTrustAnchor: Adds a new trust anchor.
removeTrustAnchor: Removes a trust anchor.
createGroup: Creates a new user, object or action group.
deleteGroup: Deletes a user, object or action group.
createObject: Creates a new object (resource).
deleteObject: Deletes an object (resource).
createObjectNamespace: Creates a new object namespace.
deleteObjectNamespace: Deletes an object namespace.
manageObjectGroups: Adds/deletes objects to an object group.
manageUserGroups: Adds/deletes objects to an user group.
createServiceType: Creates a new service type.
deleteServiceType: Deletes service type.
manageServiceAction: Adds/deletes service type and action mapping.
manageServiceActionGroups: Creates/deletes a new service/action group.
grant: Grants a user the right to perform service/action (or a group of service/actions) on a resource (or a group of resources).
revoke: Revokes a user's right.
whoami: Returns the CAS nickname associated with the user.
list: Returns the list of users/objects/service/action types.
findApplicablePolicy: Returns all relevant policy for a said user/object/service/action.
getCasObject: Returns the user/object/service/action represented by Object given a id.
getGroupMembers: Returns all members for a given user/object/servce/action group.
getAssertion: Returns an assertion for a said query that contains the rights that the user for the action and resource specified in the query.
SAMLRequest: Returns a SAML Response for a said SAML Rquest, which contains a SAML Query. This is the implementation of the OGSA AuthZ specification for authorization service.

4.2.3. Resource properties

ServerDN: The DN from the credentials used by the CAS Service
VODescription: This is a string that describes the VO relevant to CAS Service.

4.2.4. Faults

NoPermissionFault: Throws if the client is not allowed to invoke the operation.
CasFault: Throws if any other error occurs.

4.2.5. WSDL and Schema Definition

4.3. Semantics and syntax of non-WSDL protocols

[describe non-WSDL protocols. if none, state so.]

4.4. Command-line tools

Please see the CAS Admin Command Reference and CAS Query Command Reference.

4.5. Overview of Graphical User Interfaces

There is no GUI for CAS.

4.6. Semantics and syntax of domain-specific interface

To get a handle for the CAS service port type, the org.globus.cas.impl.client.CasClientSetup class can be used.
Sample Code:
To get a handle to a CAS service with instance URL instanceURL and identity serviceIdentity:
```
CasClientSetup clientSetup = new CasClientSetup();

CommunityAuthorizationServicePortType casPort = 

    clientSetup.getCASPort(instanceURL, serverIdentity);
```
To generate a proxy with embedded CAS assertions the API in the class org.globus.cas.impl.client.CasProxyHelper can be used. The class org.globus.cas.impl.client.ClientParams is used to pass in appropriate parameters and the datatype org.globus.cas.impl.client.ResourceActionsMap is used to represent the resource/actions mapping for which assertions are requested on.
Listed below is sample code that uses the client side util API to generate a proxy with CAS assertions embedded in it.
1. The ClientParams class is used to construct the parameter. If the default constructor is used and none of the values are set then the requested assertion lifetime is set to 24 hours, the default proxy file is used and the proxy containing the embedded assertions is named with a ".cas" extension at the end of the proxy file.
```
ClientParams clientParams = new ClientParams();
```
2. The following is used to set assertion lifetime. If not set then 24 hours is used.
```
clientParams.setAssertionLifetime(lifetime);
```
3. Set the file name of the proxy to use. If not set then the default credential is used.
```
clientParams.setProxyFileName(proxyFilename);
```
4. Set the file name that the proxy with CAS assertions will be written to. If not set then original proxy file name is appended with a tag.
```
clientParams.setCasProxyFileName(casProxyFilename);
```
5. Set the extension to append to the original proxy filename. If not set then the extension ".cas" is used. The extension is only used if a filename for the CAS proxy is not set.
```
clientParams.setCasProxyTag(tag);
```
6. Set the resource/actions for which the assertion is requested on. It uses an array of data type ResourceActionsMap (explained below).
```
clientParams.setResourceActionsMap(resActions);
```
7. The ResouceActionsMap datatype is used to represent the resource and the actions on the resource for which the permissions are required. It uses a String to represent the resource and a vector of strings to represent the actions.
  The resource should be of the form "objectNamespace|objectName". The action should be of the form "serviceType actionName".
8. Create an instance of the Helper class:
```
CasProxyHelper casProxyHelper = new CasProxyHelper(instanceURL, serverIdentity);
```
  Where:
  - instanceURL is the URL used to contact the CAS service.
  - serverIdentity is the expected identity of the server. If null, host authorization is used.
9. Generate the proxy with CAS assertions:
```
String casProxyFilename = casProxyHelper.getCasProxy(clientParams);
```
  This method contacts the CAS service, retrieves assertions, embeds the assertions in a proxy credential and returns the path to the proxy file.

4.7. Configuration interface

4.7.1. Configuration overview

The CAS service can be configured with the following :

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.

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

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

4.7.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 6. 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

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

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

4.7.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 7. 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 sceanrio is described here.

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

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

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

4.8. Environment variable interface

All CAS client programs use the following environment variables to determine the appropriate URL to connect to and server identity to expect. In all cases, the command line options takes precedence over the environment variables.

The URL is determined using this algorithm:
- If the -c command line option was specified, the URL specified with that option is used.
- Otherwise, the CAS_SERVER_URL environment variable must be set, and its value is used.
The server identity (i.e. the expected subject name of the CAS server certificate) is determined as follows:
- If the -s command line option was specified, the value specified with that option is used as the identity
- Otherwise, if the CAS_SERVER_IDENTITY environment variable is set, the value of that variable is used as the expected server identity. Ensure that the value is enclosed within double quotes if there are spaces in the DN. The double quotes are required by the CAS scripts when they are run from a Windows shell, although the shell does not require it even if the value has spaces.
- If neither is set, host authorization is done and the expected server credential is cas/<fqdn>, where <fqdn> is the fully qualified domain name of the host on which the CAS service is up.

5. Usage scenarios

Typically in a VO a single CAS service is run and several clients contact the service to retrieve assertions about operations on resources. These assertions can be then presented to the resources to gain access. Users with some administrative rights can grant/revoke access to these resources.

The toolkit ships with clients for users to retrieve and embed assertions in proxy and another to use that proxy to run some executable. Listed below are some helper methods in the client package that maybe used for writing other clients for the CAS service. Refer to code and/or Java Docs for more information.

For more information, see the domain section here.

6. Tutorials

There are no tutorials available at this time.

7. Debugging

Log output from the CAS server is a useful tool for debugging issues. Logging in CAS server code is based on the Jakarta Commons Logging API and is described in more detail here. As described in above section, configuration files need to be edited to enable logging at different levels. For example, to see all logging for the CAS server, the following lines need to be added:

# Server code
log4j.category.org.globus.cas.impl.service=DEBUG 

# Database access module
log4j.category.org.globus.cas.impl.databaseAccess=DEBUG

Debugging information from CAS clients can be obtained by using the -debug option on the command line.

8. Troubleshooting

8.1. Command run using cas-wrap does not pick up CAS proxy

Some commands require environment variables to be passed explicitly to the command (e.g java). If running such command through cas-wrap, place the command in a script (passing in the environment variable) and execute the script through cas-wrap.

For example, to run java -DX509_USER_PROXY=$X509_USER_PROXY org.some.java.Client, create a script client-script with following contents:

java -DX509_USER_PROXY=$X509_USER_PROXY org.some.java.Client

Ensure that the script has executable permissions and run:

 cas-wrap -t sometag client-script

8.2. CAS client fail with database permission error

CAS clients fail with database permission exception similar to:

Caused by: ERROR: permission denied for relation service_type_action

]; nested exception is:org.globus.cas.impl.databaseAccess.CasDBException:

	Note
	This is a specific instance of an error for the relation service_type_action. This error could be raised on any relation on the table.

Check that the user configured for accessing the database has the correct permissions on the database. The configuration is found in $GLOBUS_LOCATION/etc/globus_cas_server/jndi-config.xml. Typically the same username/password that is used to create the database should be used in the above configuration file since this will prevent permission issues.

9. Related Documentation

Prev	Up	Next
GT 4.1.2 CAS User's Guide	Home	GT 4.1.2 CAS Public Interfaces