The CAS service could run with its own set of credentials. Instructions to obtain service credentials may be found here.

The standard administrator clients that come with the distribution can be used to perform host authorization and expect that the CAS service have credentials that have service name "cas". The command in the above mentioned web page may be altered as follows:

  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 location of certificate and key files is referred to as CAS_CERT_FILE and CAS_KEY_FILE, respectively.

CAS uses a backend database to store all user data. Any JDBC compliant database may be used. This section describes briefly the installation of such a databaseand the creation of the database using schema required for the CAS backend.

Any JDBC compliant database may be used. PostgreSQL has been used for development and testing. The drivers for the same are included in the distribution. If a different database is used, the corresponding driver should be added to GLOBUS_LOCATION/lib.

Brief instructions to install a JDBC compliant database and specifically PostGres can be found here. For more detailed instructions, please refer to specific database documentation.

The schema of the database that needs to be created for CAS can be found at $GLOBUS_LOCATION/globus_cas_service/casDbSchema/cas_pgsql_database_schema.sql

To create a database, for example casDatabase, on a PostgreSQL, install on local machine:

casadmin$ createdb casDatabase  
casadmin$ psql -U casadmin -d casDatabase -f  \
          $GLOBUS_LOCATION/globus_cas_service/casDbSchema/cas_pgsql_database_schema.sql

You will see a list of notices on the screen. Unless any of them say "ERROR", these are just output for information.

Information about the database needs to be configured as described here for the CAS service to be able to use it.

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

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

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

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. 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 and organized. She now wants to add some resources. Because the community currently has a single FTP server, foo.bar.edu, available to it, she will add this to the CAS database.

Each resource or object in the CAS server has a namespace associated to it that defines certain features. For example, it can define the comparison algorithm that needs to be used when this object name is used for comparison. 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 bootup. 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 indiviual directory, add an object for the directory. For example, if Alice would like to be able to manipulate the data 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 the community will end up with 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 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 described object, ftp://foo.bar.edu/data/* in namespace FooFTPNamespace, to 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 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 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 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 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.