Table of Contents
- 1. Overview
- 2. Files and directories in CAS
- 3. Configuring the CAS server to work with the GridFTP server
- 3.1. Step 1: Set up the CAS server.
- 3.2. Step 2: Run the CAS server with host credentials
- 3.3. Step 3: Enable CAS support in the GridFTP server
- 3.4. Step 4: Configure the GridFTP server to trust the CAS server
- 3.5. Step 5: Add a CAS administrator
- 3.6. Step 6: Add a CAS user group
- 3.7. Step 7: Add a CAS user
- 3.8. Step 8: Add user to the user group
- 3.9. Step 9: Add CAS object
- 3.10. Step 10: Add permission for users
- 4. Transferring files using CAS and GridFTP
- 5. Managing policy
- 6. Authorization Enforcement at the GridFTP Server
This document is intended to be used with the CAS and GridFTP documents, to configure and use CAS with GridFTP.
CAS is used to administer access rights to files and directories and GridFTP server can be configured to enforce those rights. The following is an overview of the process:
- A CAS administrator sets up rights on the CAS server.
- A user retrieves those rights in the form of a signed assertion and presents it to the GridFTP server at the time of access.
- If the assertion presented has the necessary permissions and the GridFTP server trusts the CAS server that issued it, access is allowed.
In a default Globus Toolkit installation, CAS is installed with a set of credentials associated with the CAS server. A CAS administrator has all rights on the CAS server and manages users. To be used with GridFTP, the administrator needs to add users, add the files and directories he wants protected and grant specific rights to the files.
The user then retrieves a CAS assertion from the server, for either specific files/directories or all his access rights stored in CAS. This is done using the client side command, cas-proxy-init, which embeds the assertion in the user's proxy. Another client side command, cas-wrap can then be used to run the GridFTP command, globus-url-copy, to ensure that the proxy is used.
Details about the CA who issues these credentials needs to be added to the CAS server as a trust anchor. Each user has a nick name, a subject DN and is associated with a trust anchor. A particular user is designated as superuser, so has permissions to add users and manager rights. This can be set up using the bootstrap step.
Users who are not administrators can be added using command line tools. Permissions in a CAS database are granted to user groups, rather than users. So a user group needs to be created and users added to it prior to assigning permissions.
Files and directories are "objects" in CAS. Each object has a name and a namespace assocated with it. The namespace determines the scope of the object and also the comparison method to use with object names. A predefined namespace, called FTPDirectoryTree is loaded in the CAS database upon bootstrap and this is the namespace expected for GridFTP objects.
For example, if permission on file "some_file_path" on host "somehost.edu" needs to be managed, it needs to be added as an object, with name "ftp://somehost.edu/some_file_path" and namespace "FTPDirectoryTree". This object "ftp://somehost.edu/some_file_path" will be recognized by the CAS-enabled GridFTP server at "somehost.edu" as referring to the file named "some_file_path". An object in the FTPDirectoryTree namespace with the name "ftp://somehost.edu/some_directory_path/*" will be recognized by the CAS-enabled GridFTP server at "somehost.edu" as referring to all files and directories under "some_directory_path".
In some cases, it may be desirable to have a GridFTP server recognize CAS assertions that use a hostname other than the server's fully qualified domain name. Starting the GridFTP server with the option "-H otherhost" will cause the GridFTP server to recognize objects with names that start with "ftp://otherhost/" instead.
The actions that are allowed on a file and a directory are listed in the following table:
| Action | Result for a file | Result for a directory |
|---|---|---|
| read | Gives permission to read the file. | Gives permission to chdir to the directory. |
| lookup | Gives the right to get Unix stat() information. | Gives the right to chdir to and to list the contents of the directory. |
| write | Allows modification of an existing file. | Gives the right to chdir to the directory. |
| create | Allows creation of the file if it does not exist. | Allows creation of the directory if it does not exist and gives the right to chdir to the directory if it does exist. |
| delete | Allows deletion of the file. | Allows deletion of the directory, if empty; also gives the right to chdir to the directory. |
| chdir | Does not apply. | Allows making the directory the current default directory. |
These actions are predefined and loaded onto CAS database when bootstrap is done. Apart from these actions on files/directories, there is another action "authz_assert" which is used to override the existing assertions (either from proxy or from a previous "authz_assert" command) with the assertions received over the GridFTP control channel. FTP clients can use the command "SITE AUTHZ_ASSERT" to send assertions to the GridFTP server.
The following is a summary of supported FTP commands and the permissions they require:
| Typical Client Commande | FTP Protocol Command | Rights Required |
|---|---|---|
| get | RETR | read |
| put | STOR | write, if file exists; create, if file does not exist |
| delete | DELE | delete |
| ls | LIST | lookup |
| chdir | CWD | any of: chdir, lookup, read, write, create, or delete |
| mkdir | MKD | create |
| rmdir | RMD | delete |
| rename | RNFR / RNTO | read and delete on old file; write on new file, if it exists, create on new file, if it does not exist |
Run the CAS server with host credentials /O=Grid/OU=test/CN=foo.bar.edu.
![[Note]](../../../../../docbook-images/note.gif) | Note |
|---|---|
The CA that issues these credentials should be trusted by the GridFTP server. Setting up of trusted CA is described here |
The GridFTP Server reads two files (gsi-authz.conf and gsi-gaa.conf) to determine how to perform certain authorization and mapping functions. If these files are not present (as is the case after a standard Globus Toolkit installation), the GridFTP server will not support CAS authorization (that is, the GridFTP server will ignore the CAS policy assertions in the user's credential and determine the user's permissions based solely on the user's identity).
Run [setup-globus-gaa-authz-callout] to create gsi-authz.conf
and gsi-gaa.conf files that will cause the GridFTP server to honor CAS policy
assertions. There are two ways to run this command:
To create the config files in the directory /etc/grid-security (where the GridFTP server looks for them by default), run the following as root:
$GLOBUS_LOCATION/setup/globus/setup-globus-gaa-authz-callout
To create the config files to another directory, run:
$GLOBUS_LOCATION/setup/globus/setup-globus-gaa-authz-callout -d mydir
Where 'mydir' is the path to the desired directory. You then must make sure the GridFTP server finds these files by setting the following environment variable before starting the GridFTP server:
- Set GSI_AUTHZ_CONF to mydir/gsi-authz.conf.
- Set GSI_GAA_CONF to mydir/gsi-gaa.conf.
By default, setup-globus-gaa-authz-callout will not overwrite an existing configuration file. Use the following options to overwrite existing GridFTP config files:
- Use the -force option to overwrite an existing gsi-authz.conf file
- Use the -overwrite_gaa_config option to overwrite an existing gsi-gaa.conf file.
The previous step configured the GridFTP server to understand CAS credentials. However, the GridFTP server will not allow a user authenticating with a CAS credential to perform any action that it would not allow the CAS server itself to perform. To configure the GridFTP server to trust a particular CAS server:
- Create a local user account corresponding to the CAS server.
- Use file permissions to allow that user account to have the desired level of file access.
- Create a gridmap entry that maps the CAS server's distinguished name to that local account.
Add a CAS admin, we'll use the CAS nickname, "casAdmin", and DN "/O=Grid/OU=test/CN=CAS Administrator". This credential is issued by a CA with certificate "/O=Grid/OU=test/CN=CA"
This can be setup during bootstrap and below is the bootstrap file for the above scenario.
ta-name=defaultTrustAnchor ta-authMethod=X509 ta-authData=/O=Grid/OU=test/CN=CA user-name=superUser user-subject=/O=Grid/OU=test/CN=CAS Administrator userGroupname=superUserGroup
Since permissions are only on user groups, we need to add a user group, for example "readGroup". This can be done using cas-group-admin.
cas-group-admin user create superUserGroup readGroup
| Note |
|---|---|
The superUserGroup here determined the user group that has permissions to manipulate the group that is being created i.e readGroup. |
Add the user who needs access to files. For example, add User1, with DN "/O=Grid/OU=test/CN=User 1" issued by the CA in [Step 4], using [cas-enroll]:
cas-enroll user superUserGroup User1 "/O=Grid/OU=test/CN=User 1" defaultTrustAnchor
| Note |
|---|---|
The superUserGroup here determined the user group that has permissions to manipulate the user that is being created i.e User1. |
To add the CAS user to the CAS user group, use cas-group-add-entry:
cas-group-add-entry user readGroup User1
Add the file (on which you want to set permissions) as a CAS object with the name "ftp://foo.bar.edu/tmp/file1" and namespace "FTPDirectoryTree":
cas-enroll object superUserGroup "ftp://foo.bar.edu/tmp/file1" "FTPDirectoryTree"
| Note |
|---|---|
The superUserGroup here determined the user group that has permissions to manipulate the object that is being created. |
To give permissions to all files in a directory, create the CAS object with a wild card "*". For example, object name "ftp://foo.bar.edu/tmp/admin/*". If permission is given on this object, all files in that directory are affected.
For example, if you create a new user group called "adminGroup", you give read permission to all users in that group as follows, any user in "adminGroup" can read any file in "/tmp/admin" on that server.
cas-rights-admin grant adminGroup object FTPDirectoryTree "ftp://foo.bar.edu/tmp/admin/*" serviceAction file read
Add permission for users in "readGroup" to be able to read object added in the previous step.
cas-rights-admin grant readGroup object FTPDirectoryTree "ftp://foo.bar.edu/tmp/file1" serviceAction file read
Now any user added to readGroup can read the file (that was added in Step 9).
Once the CAS server has been configured (as above), if User1 wants to transfer the file "/tmp/file1" on "ftp://foo.bar.edu", User1 performs the following two steps:
Runs cas-proxy-init to get the CAS assertion:
cas-proxy-init -p casProxy
Note This gets the assertion from the CAS server, generates a proxy with the assertion and writes it out to "casProxy".
Runs cas-wrap to transfer the file:
cas-wrap -p casProxy globus-url-copy gsiftp://somehost.edu/some_file_path file:///some_file_path
The CAS administrator can create groups of users and groups of objects to ease policy management.
Also, if the administrator wants to provide a set of rights, such as read and lookup, the administrator can create a service action group with these action as members. User groups can then be provided with access to all actions in the group.
Similarly the administrator can create groups of objects, which would be a group of GridFTP server and files on it, and grant access rights to users.
The following describes how the GridFTP server processes a file transfer using CAS:
- During the authentication phase, GridFTP server extracts the CAS assertion in the proxy credentials and stores it.
- If the GridFTP server receives a CAS assertion over the control channel, it overwrites the old assertion (if any) with the new one.
- Upon receiving a file transfer request, the GridFTP server looks for a CAS assertion.
- If the assertion is present, checks whether the file being accessed has permission. If assertion has permission for the file, the access is allowed. Otherwise an error is thrown.
- If no CAS assertion is found, the presence of user DN is checked in the gridmap file. If DN exists, then access is allowed. Otherwise an error is thrown.