CAS: Administrator's Guide

Contents

The CAS administrator clients can be used to manipulate and maintain the data in CAS database. It allows one to enroll (and unenroll) CAS Objects, create (and delete) groups, add (and remove) members from groups, 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 to 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 to, has permission "superuser" on cas server object, then they may perform any operation, even if they donot have 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 operations on that object.

The CAS Query commands donot 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.

Scripts have been provided for all command line clients. The scripts are placed in GLOBUS_LOCATION/bin. This directory needs to be added to the PATH to be able to execute these scripts from other location. An environment variable GLOBUS_LOCATION must be set to point to GT3 Install Location. Some of the options that are common to all the clients are described here.

Client Options:
The options that are common to all clients are
 [-debug -help -v -c cas-url -s server-identity] 
Note: If you have a asterix (*) in your command, you might have to escapeit with backslash.

Using the CAS administrator command line clients

Enrolling and Unenrolling Trust Anchors

To enroll a trust anchor, the user must have cas/enroll_trustAnchor permission on that cas server object(that is, must have permission to perform the enroll_trustAnchor action on the cas service type). The enroll operation allows the user to choose a user group to which cas/grantAll permission on the enrolled object should be granted. The nickname should be unique across the CAS database and is used to refer to this trust anchor.

  casAdmin$ cas-enroll [options] trustAnchor userGpName nickname authMethod authData

where: To unenroll a trust anchor, the user must have cas/unenroll permission on that trust anchor. The trust anchor must also be unused, that is there may not be any users in the database that have this trust anchor or it may not be a part of any object group.

  casAdmin$ cas-remove [options] trustAnchor nickname
where: If the trust anchor nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that trust anchor is purged.

Enrolling and Unenrolling Users

To enroll a user, the user must have cas/enroll_user permission (that is, must have permission to perform the enroll_user action on the cas service type). The enroll operation allows the user to choose a user group to which cas/grantAll permission on the enrolled object should be granted. The enrolled user also gets all the privileges granted to the community. The nickname should be unique across the CAS database and is used to refer to this user.

  casAdmin$ cas-enroll [options] user userGpName nickname subjectName trustAnchorNick
where: To unenroll a user, the user must have cas/unenroll permission on that user. The user must also be unused, that is, there may not be any user groups in the database that have this user as a member.
  casAdmin$ cas-remove [options] 
	  user nickname
where: If the user nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that user is purged.

Enrolling and Unenrolling Namespaces

To enroll a namespace, the user must have cas/enroll_namespace permission (that is, 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: The two comparison classes provided as a part of the distribution are

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

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

Enrolling and Unenrolling Objects

To enroll a object, the user must have cas/enroll_object permission (that is, 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: To unenroll a 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: 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.

Enrolling and Unenrolling Service Type

To enroll a service type, the user must have cas/enroll_serviceType permission (that is, 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: 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 have 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.

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

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

Maintaining User Groups

To create a new user group, the user must have cas/create_user_group permission(thats is, must have permission to perform create_user_group action on 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 : 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: 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:

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 should not be a memeber of some object group and such).

  casAdmin$ cas-group-admin [options] user delete groupName
where: If the user group specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that user group is purged.

Maintaining Object Groups

To create a new object group, the user must have cas/create_object_group permission(thats is, must have permission to perform create_object_group action on 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: 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 a 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: To remove an object from a 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 If the group member being removed does not exist, an error is not thrown.

To delete a 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: If the object group specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that user group is purged.

Maintaining Service/Action Groups

To create a new service/action group, the user must have cas/create_serviceAction_group permission(that is, must have permission to perform create_serviceAction_group action on 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: To add to a service/Action to a serviceAction group, the user must have cas/add_group_entry permission on that particular serviceAction group (that is, 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 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: 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. (for example should not be a memeber of some object group and such)

  casAdmin$ cas-group-admin [options] serviceAction delete groupName
where: 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.

Maintaining Permissions

The user may grant permissions to a user group, on a 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:

  casAdmin$ cas-rights-admin [options] grant userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec
where: The user may revoke a policy in the CAS database provided the user has cas/revoke permission on the object or object group on whch the policy is defined.
  casAdmin$ cas-rights-admin [options] revoke userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec
where:

Using CAS Query Command line clients

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.

Example 1:

  casUser$ cas-whoami [options]
where Returns the CAS user nick of the client.

Example 2:

  casUser$ cas-list-object [options] type
where Returns a list of CasObjects in the database of the requested type.

Example 3:

  casUser$ cas-get-object [options] type name
where Returns the particular object of the said type and name.

Eample 4:

  casUser$ cas-group-list-entries [options] type name
where Returns list of group members.

Example 5:

  casUser$ cas-find-policies [-c cas-url] type name
where Returns all applicable policies, both policies that are implicit to the CAS server and those that are external.

Example of CAS Server Administration

Alice, Bob and Carol are three members of a community who have set up a Community Authorization service. Alice's role is primary to administer the CAS server. Bob is an analyst who needs read access to much of the community data. Carol is a scientist who needs to be able to both read and write community data.

These examples show how Alice adds the users Bob and Carol to the CAS server, then adds a ftp server with some data available to the community and then add permissions for the users using the cas administration clients.

These examples assume that Alice has installed the CAS server and bootstrap the database with herself as super user. Please refer to installation documentation for details.

Assume Alice's nickname on the CAS server is alice and at bootstrap has created a user group suGroup,which has super user permissions on the database. Say, the CAS serivce URL is http://localhost:8080/ogsa/services/base/cas/CASService

All commands listed below assume that enviroment variable GLOBUS_LOCATION has been set to point to the GT3 core install and that the commands are run ftom GLOBUS_LOCATION/bin. Also, say an environment variable CAS_SERVER_URL has been set to point to the CAS server URL, http://localhost:8080/ogsa/services/base/cas/CASService

1. Adding a user group

Since at the time of booting up the CAS server, only one user group that has super user permissions on the CAS server is created, Alice might want to create another user group to which new users maybe added and permissions to newly enrolled CAS entities may be given. This also eases the process of giving same rights to many users.Given they 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. Say, Alice would like 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 scientist

2. Adding trust anchor.

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

Say, Alice and Carol share a trust anchor different from Bobs's. Then Alice needs to add the trust anchor used by Bob by using 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, who uses X509 as 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, would present credentials signed by this trust anchor.

3. Adding users.

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 reference to trust anchor used by the user. As with any entity added to the CAS server, a user group whose members will have all permissions on that entity needs to be chosen. Say, Alice would like the members of user group suUser to be able to maninipulate the user entity Bob.

alice% cas-enroll user suUser bob "/O=Our Community/CN=Bob Foo" AbcTrust
Alice uses a simliar command to add Carol to the CAS database.

4. Adding users to user group.

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 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 nick name of the user who needs to be added. So to add Bob to analysts group, the command would be,

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

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

4. Adding a new FTP server.

Alice now has the community users in the database and organized. She now wants to add some resources. The community currently has a single ftp server, foo.bar.edu, available to it, so she is going to add this to the CAS database.

Each resource or object in the CAS server has a namespace associated to it that defines some features like the comparison algorithm that needs to be used when this object name is used for comparison and maybe the base URL that should be prefixed to objects that belong to this namespace. In this case, Alice can chooses to use FTPDirectoryTree namespace that is added to the CAS server at bootup. Now, she adds the ftp server to the CAS database, using the cas-enroll client with the object option.

alice% cas-enroll object suGroup ftp://foo.bar.edu/* FTPDirectoryTree
This 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 indiviual directories, objects with the directory. Say, if Alice would like to be able to manipulate the data on the server as a separate entity, the the following will add an object for that.

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

4. Creating an object group

Alice suspects the community will end up have more directories containing data on other servers that will have identical polices as the /data directory on foo.bar.edu. So 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 group and create option.

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.

5. Adding members to object 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 described object, ftp://foo.bar.edu/data/* in namespace FooFTPNamespace, to object group data, the following would be the command.

alice% cas-group-add-entry object data object FooFTPNamespace ftp://foo.bar.edu/data/*
In the above command, the first object refers to the group type, data is the name of the object group, object refers to the type of CAS entity that is being added as memeber and the last two parameters define the namespace and the object that needs to be added.

6. Adding service types

Alice now needs to add information about the kind 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 serviceType option maybe used. To add a service type called file and give members of suGroup all rights on this service type, she uses the following command.

alice% cas-enroll serviceType suGroup file

7. Adding action mappings

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 add option. The following command should add a mapping of action read to service type file.

alice% cas-action add file add
Similarly she can add other mapping like write to this service type.

8. Grant permissions.

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 data group to the analysts and scientists, namely read permissions to the analysts and read and write permissions to the scientists.

To grant permissions the cas-rights-admin with the grant option needs to be used. To give read permissions to the analysts group, the command that needs to be run would be

alice% cas-rights-admin grant analysts objectGroup data serviceAction file read
She similarly grants rights to scientists group.
Updated: 07 - 30 - 2003