Using CAS Command line Clients

1. CAS Administrator clients

The CAS administrator clients can be used to manipulate and maintain the data in the CAS database. It allows one to enroll (and unenroll) CAS Objects, create (and delete) groups, add (and remove) members from groups, and add (and remove) service type and action mappings. Typically these operation are performed by the CAS Administrator.

All enroll operations involve granting cas/grantAll permission on the enrolled object to some user group (to which the user may belong or otherwise).

All operations require that the user have specific permissions to perform the operation. Permissions and policies are given and applied to user groups. Hence a user is said to have permission to perform an operation if one of the user groups that the user belongs to has permission to perform that operation.

If some user group to which the user belongs has permission "superuser" on cas server object then they may perform any operation, even if they do not have the specific rights that are outlined below for each operation.

If a user has cas/grantAll permission on any object, then the user is permitted to perform any operation on that object.

1.1. Enrolling and Unenrolling Namespaces

To enroll a namespace, the user must have cas/enroll_namespace permission (that is, the user must have permission to perform the enroll_namespace action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled object. The comparison algorithm specified should be the name of the Comparison class that needs to be used to compare objects that belong to this namespace. The nickname should be unique across the CAS database and is used to refer to this user.

            casAdmin$ cas-enroll [options] namespace userGpName nickname basename comparisonAlg
            
        

where:

  • options: Client options
  • userGpName: The user group to which cas/grantAll permission should be granted on this trust anchor entity
  • nickname: The namespace nickname
  • basename: The base URL for the name space
  • comparisonAlg: The comparison algorithm to be used. Unless the standard comparison algorithms described below are used, the fully qualified name of the class that needs to be used should be given. The class needs to extend from the abstract class org.globus.cas.impl.service.ObjectComparison.

The two comparison classes provided as a part of the distribution are:

  • ExactComparison: This class does a case-sensitive exact comparison of the object names. If comparisonAlg in the above method is set to "ExactComparison", the class in the distribution is loaded and used.
  • WildcardComparison: This class does wild card matching as described in "CAS Simple Policy Language". (FIXME link to that doc) It assumes that the wild card character is "*" and "/" is the file separator. If comparisonAlg in the above method is set to "WildCardComparison", the class in the distribution is loaded and used.

Also two namespaces are added to the CAS database at boot up time, other than the inherent CAS Namespace.

  • FTPDirectoryTree: Uses the WildCardComparison Algorithm and has the base URL set to the current directory.
  • FTPExact: Uses the ExactComparison Algorithm and has the base URL set to the current directory.

To unenroll a namespace, the user must have cas/unenroll permission on that namespace. The namespace must also be unused—that is, there may not be any object in the database that belongs to this namespace.

            casAdmin$ cas-remove [options] namespace nickname
            
        

where:

  • options: Client options
  • nickname: The nickname of the namespace to be unenrolled.

If the namespace nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that namespace is purged.

1.2. Enrolling and Unenrolling Objects

To enroll an object, the user must have cas/enroll_object permission (that is, the use must have permission to perform the enroll_object action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled object. The name of the object and the the namespace this object belongs to identifies an object in the database and should be unique across the CAS database.

            casAdmin$ cas-enroll [options] object userGpName objectName namespaceNick
        

where:

  • options: Client options
  • userGpName: The user group to which cas/grantAll permission should be granted on this trust anchor entity.
  • objectName: The name of the object.
  • namespaceNick: The nickname of the namespace this object belongs to.

To unenroll an object the user must have cas/unenroll permission on that object. The object must also be unused—that is, there may not be any object group in the database that this object belongs to.

            casAdmin$ cas-remove [options] object objName namespaceNick
            
        

where:

  • options: Client options
  • objName: The name of the object to be unenrolled.
  • namespaceNick: The nickname of the namespace this object belongs to.

If the object specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that object is purged.

1.3. Enrolling and Unenrolling Service Type

To enroll a service type, the user must have cas/enroll_serviceType permission (that is, the user must have permission to perform the enroll_serviceType action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled service type. The service type name should be unique across the CAS database.

            casAdmin$ cas-enroll [options] serviceType userGpName serviceTypeName
        

where:

  • options: Client options
  • userGpName: The user group to which cas/grantAll permission should be granted on this trust anchor entity.
  • serviceTypeName: The service type name.

To unenroll a service type the user must have cas/unenroll permission on that service type. The service type must also be unused—that is, there may not be any service type to action mapping.

            casAdmin$ cas-remove [options] serviceType serviceTypeName
            
        

where:

If the service type specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that service type is purged.

1.4. Maintaining Service Types

To add an action mapping to a service type, the user must have cas/create_group_entry permission on the service type.

            casAdmin$ cas-action [options] add serviceTypeName actionName
        

where:

  • options: Client options
  • serviceTypeName: The service type name.
  • actionName: The action name.

To remove a service type action mapping the user must have cas/delete_group_entry permission on the service type.

            casAdmin$ cas-action [options] remove serviceTypeName actionName
            
        

where:

  • options: Client options
  • serviceTypeName: The service type name.
  • actionName: The action name.

If the group member being removed does not exist, an error is not thrown.

1.5. Maintaining User Groups

To create a new user group the user must have cas/create_user_group permission (that is, the user must have permission to perform the create_user_group action on the cas service type). The user group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created user group. If the user group that is chosen to have cas/grantAll permission is the new group created, then the user making this request is added to the new group.

            casAdmin$ cas-group-admin [options] user create userGpName groupName
        

where :

  • options: Client options
  • userGpName: The user group to which cas/grantAll permission should be granted on this trust anchor entity.
  • groupName: The name of the user group being created.

To add to a user to a user group the user must have cas/add_group_entry permission on that particular user group. Only user nicknames that exist in the CAS database can be valid members.

            casAdmin$ cas-group-add-entry [options] user groupName nickname
        

where:

  • options: Client options
  • groupName: The user group name to which the member needs to be added.
  • nickname: The nickname of the user to be added to this group.

To remove a user from a user group the user must have cas/remove_group_entry permission on that particular user group.

            casAdmin$ cas-group-remove-entry [options] user groupName nickname
            
        

where:

  • options: Client options
  • groupName: The user group name to which the member needs to be added.
  • nickname: The nickname of the user to be added to this group.

If the group member being removed does not exist, an error is not thrown.

To delete a user group, the user must have cas/delete_user_group entry permission on that user group. The group must be empty and also not be referenced from other entities in the database (for example, it should not be a member of some object group).

            casAdmin$ cas-group-admin [options] user delete groupName
        

where:

  • options: Client options
  • groupName: The name of the user group to be deleted.

If the user group specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that user group is purged.

1.6. Maintaining Object Groups

To create a new object group the user must have cas/create_object_group permission (that is, the user must have permission to perform the create_object_group action on the cas service type). The object group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created object group.

            casAdmin$ cas-group-admin [options] object create userGpName groupName
        

where:

  • options: Client options
  • userGpName: The user group to which cas/grantAll permission should be granted on this trust anchor entity.
  • groupName: The name of the user group being created.

To add to a member (an object group can have the following CasObjects as members, object, user, user group, service type, namespace or trust anchor) to an object group, the user must have cas/add_group_entry permission on that particular object group.

            casAdmin$ cas-group-add-entry [options] object groupName objectSpecDesc objcetSpec
            
        

where:

  • options: Client options
  • groupName: The object group name to which the member needs to be added.
  • objectSpecDesc: The type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) service Type).
  • objectSpec: The identifier for the CasObject the user is adding (nickname (or) nickname (or) groupName (or) objectNamespace objectName (or) nickname (or) serviceTypeName).

To remove an object from an object group the user must have cas/remove_group_entry permission on that particular object group:

            casAdmin$ cas-group-remove-entry [options] object groupName objectSpec objectSpecDesc
            
        

where:

  • options: Client options
  • groupName: The user group name to which the member needs to be added.
  • objectSpecDesc: The type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) service Type).
  • objectSpec: The identifier for the CasObject the user is adding (nickname (or) nickname (or) groupName (or) objectNamespace objectName (or) nickname (or) serviceTypeName).

If the group member being removed does not exist, an error is not thrown.

To delete an object group the user must have cas/delete_user_group entry permission on that object group. The group must be empty.

            casAdmin$ cas-group-admin [options] object delete groupName
        

where:

  • options: Client options
  • groupName: The name of the object group to be deleted.

If the object group specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that user group is purged.

1.7. Maintaining Service/Action Groups

To create a new service/action group, the user must have cas/create_serviceAction_group permission (that is, the user must have permission to perform the create_serviceAction_group action on the cas service type). The serviceAction group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created serviceAction group.

            casAdmin$ cas-group-admin [options] serviceAction create userGpName groupName
        

where:

  • options: Client options
  • userGpName: The user group to which cas/grantAll permission should be granted on this trust anchor entity.
  • groupName: The name of the serviceAction group being created.

To add a service/Action to a serviceAction group the user must have cas/add_group_entry permission on that particular serviceAction group (that is, the user must have permission to perform add_group_entry action on that service action group).

            casAdmin$ cas-group-add-entry [options] serviceAction groupName serviceTypeName actionName
            
        

where:

  • options: Client options
  • groupName: The user group name to which the member needs to be added.
  • serviceTypeName: The service type name part of the mapping to be added to the group.
  • actionName: The action name part of the mapping to be added to the group.

To remove a service/Action from a serviceAction group, the user must have cas/remove_group_entry permission on that particular serviceAction group.

            casAdmin$ cas-group-remove-entry [options] serviceAction groupName serviceTypeName actionName
            
        

where:

  • options: Client options
  • groupName: The user group name to which the member needs to be added.
  • serviceTypeName: The service type name part of the mapping to be added to the group.
  • actionName: The action name part of the mapping to be added to the group.

If the action being removed does not exist, an error is not thrown.

To delete a serviceAction group the user must have cas/delete_user_group entry permission on that serviceAction group. The group must be empty and also must not be referenced from any other entity in the database. Ffor example, it should not be a member of some object group.

            casAdmin$ cas-group-admin [options] serviceAction delete groupName
        

where:

  • options: Client options
  • groupName: The name of the user group to be deleted.

If the service action group specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that serviceAction group is purged.

1.8. Maintaining Permissions

The user may grant permissions to a user group on an object or object group to perform a service action or service action group (that is, to perform any action that is a member of the service action group to which permission is granted), provided the user has has both:

  • cas/grant permission on the object or object group, and
  • permission to perform the service action or service action group on the object or object group.
            casAdmin$ cas-rights-admin [options] grant userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec
        

where:

  • options: Client options
  • userGroupName: The user group to grant permission for.
  • objectSpec: The identifier for the object or object group.
  • objectSpecDesc: The type (object or objectGroup).
  • actionSpec: The identifier for action or action group.
  • actionSpecDesc: The type (serviceAction or serviceActionGp).

The user may revoke a policy in the CAS database provided the user has cas/revoke permission on the object or object group on which the policy is defined.

            casAdmin$ cas-rights-admin [options] revoke userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec
        

where:

  • options: Client options
  • userGroupName: The user group to grant permission for.
  • objectSpecDesc: The type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) serviceType (or) userGroup (or)).
  • objectSpec: The identifier for the object or object group.
  • actionSpec: The identifier for the action or action group.
  • actionSpecDesc: The type (serviceAction or serviceActionGp).

2. Using CAS Query Clients

The CAS Query commands do not alter the state of the database and any CAS user who has cas/query permissions may use the commands to retrieve data from the CAS server.

The following queries can be run against the CAS server. These are typically used by CAS clients (who may not be administrators).

The user need cas/query permissions to perform these operations—that is, the user must have permission to query on the cas server object.

2.1. Getting user's CAS identity

            casUser$ cas-whoami [options]
        

where:

Returns the CAS user nick of the client.

2.2. Getting object list

            casUser$ cas-list-object [options] type
        

where:

  • options: Client options
  • type: trustAnchor (or) user (or) userGroup (or) object (or) objectGroup (or) objectGroup (or) namespace (or) serviceType (or) serviceAction (or) serviceActionGp.

Returns a list of CasObjects in the database of the requested type.

2.3. Getting CAS object

            casUser$ cas-get-object [options] type name
            
        

where:

  • options: Client options
  • type: trustAnchor (or) user (or) object (or) namespace (or) service Type.
  • name: nickname (or) nickname (or) objectNamesapce objectName (or) nickname (or) serviceTypeName (corresponding to the type).

Returns the particular object of the said type and name.

2.4. Getting group members

            
            casUser$ cas-group-list-entries [options] type name
        

where:

  • options: Client options
  • type: The type of the group (user (or) object (or) serviceAction).
  • name: The name of the group.

Returns list of group members.

2.5. Getting policy information

            casUser$ cas-find-policies [-c cas-url] type name
        

where:

  • [-c cas-url]: The URL of the CAS service.
  • type: trustAnchor (or) user (or) userGroup (or) object (or) objectGroup (or) namespace (or) service Type (or) serviceAction (or) serviceActionGroup.
  • name: nickname (or) nickname (or) groupName (or) objectNamespace|objectName (or) groupName (or) nickname (or) serviceTypeName (or) serviceType/Action (or) groupName (corresponding to the type).

Returns all applicable policies, both policies that are implicit to the CAS server and those that are external.

3. CAS Client common options

The following options are common to all command line clients:

 [-debug -help -v -c cas-url -s server-identity -m mechanism -p protection] 
  • CAS Service URL: The -c cas-url option can be used to set the CAS Service instance, where cas-url is the URL of the CAS service instance. Alternatively, an environment variable can be set as shown here.

    The instance URL typically looks like

    http://Host:Port/wsrf/services/CASService

    , where Host and Port are the host and port where the container with the CAS service is running.

  • CAS Service Identity: The -s server-identity option can be used to set the expected CAS server identity, where server-identity is the identity of the CAS service. Alternatively, an environment variable can be set as shown here. 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.

    [Note]Note

    If the service being contacted is using GSI Secure Transport, then the container credentials configured for the service will be used, even if service/resource level credentials are configured. Hence authorization needs to be done based on the DN of the container credentials.

  • Debug: To run the client with debug message traces and error stack traces, the -debug flag must be used.
  • Usage: The -help flag prints the usage message for the client.
  • Version number: The -v flag prints the version number.
  • Security Mechanism: The -m flag is used to set the chosen security mechanism. It can be set to 'msg' for Secure Message, 'conv' for Secure Conversation and 'trans' for Transport security. If not set and the server URL starts with 'https', Transport Security is used, else Secure Message is used.
  • Protection type: The -p flag is used to set the protection type required with the security mechanism. Can be set to 'sig' or 'enc' to indicate signature or encryption. Defaults to signature.

Note: If you have a asterisk (*) in your command, you might have to escape it with backslash.