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.
[-debug -help -v -c cas-url -s server-identity]
http://GT3Host:GT3Port/ogsa/services/base/cas/CASServicewhere GT3Host and GT3Port are host and port where container with CAS service is running.
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 authDatawhere:
casAdmin$ cas-remove [options] trustAnchor nicknamewhere:
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 trustAnchorNickwhere:
casAdmin$ cas-remove [options] user nicknamewhere:
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 comparisonAlgwhere:
Also two namespaces are added to the CAS database at bootup time, other than the inherent CAS Namespace.
casAdmin$ cas-remove [options] namespace nicknamewhere:
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 namespaceNickwhere:
casAdmin$ cas-remove [options] object objName namespaceNickwhere:
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 serviceTypeNamewhere:
casAdmin$ cas-remove [options] serviceType serviceTypeNamewhere:
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 actionNamewhere:
casAdmin$ cas-action [options] remove serviceTypeName actionNamewhere:
If the group member being removed does not exist, an error is not thrown.
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 groupNamewhere :
casAdmin$ cas-group-add-entry [options] user groupName nicknamewhere:
casAdmin$ cas-group-remove-entry [options] user groupName nicknamewhere:
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 groupNamewhere:
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 groupNamewhere:
casAdmin$ cas-group-add-entry [options] object groupName objectSpecDesc objcetSpecwhere:
casAdmin$ cas-group-remove-entry [options] object groupName objectSpec objectSpecDescwhere
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 groupNamewhere:
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 groupNamewhere:
casAdmin$ cas-group-add-entry [options] serviceAction groupName serviceTypeName actionNamewhere
casAdmin$ cas-group-remove-entry [options] serviceAction groupName serviceTypeName actionNamewhere:
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 groupNamewhere:
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 actionSpecwhere:
casAdmin$ cas-rights-admin [options] revoke userGroupName objectSpecDesc objectSpec actionSpecDesc actionSpecwhere:
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
Example 2:
casUser$ cas-list-object [options] typewhere
Example 3:
casUser$ cas-get-object [options] type namewhere
Eample 4:
casUser$ cas-group-list-entries [options] type namewhere
Example 5:
casUser$ cas-find-policies [-c cas-url] type namewhere
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 analystsThis 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" AbcTrustAlice 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/* FTPDirectoryTreeThis 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 dataThis 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 addSimilarly 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 readShe similarly grants rights to scientists group.