GT4 CAS User's Guide

1. Introduction

The CAS User's Guide provides general end user-oriented information.

Building on the Globus Toolkit® Grid Security Infrastructure (GSI), CAS allows resource providers to specify course-grained access control policies in terms of communities as a whole, delegating fine-grained access control policy management to the community itself. Resource providers maintain ultimate authority over their resources but are spared day-to-day policy administration tasks (e.g. adding and deleting users, modifying user privileges).

1.1. How it works

  1. A CAS server is initiated for a community: a community representative acquires a GSI credential to represent that community as a whole, and then runs a CAS server using that community identity.
  2. Resource providers grant privileges to the community. Each resource provider verifies that the holder of the community credential represents that community and that the community's policies are compatible with the resource provider's own policies. Once a trust relationship has been established, the resource provider then grants rights to the community identity, using normal local mechanisms (e.g. grid map files and disk quotas, file system permissions, etc).
  3. Community representatives use the CAS to manage the community's trust relationships (e.g., to enroll users and resource providers into the community according to the community's standards) and grant fine-grained access control to resources. The CAS server is also used to manage its own access control policies; for example, community members who have the appropriate privileges may authorize additional community members to manage groups, grant permissions on some or all of the community's resources, etc.
  4. When a user wants to access resources served by the CAS, that user makes a request to the CAS server. If the CAS server's database indicates that the user has the appropriate privileges, the CAS issues the user a GSI restricted proxy credential with an embedded policy giving the user the right to perform the requested actions.
  5. The user then uses the credentials from the CAS to connect to the resource with any normal Globus tool (e.g. GridFTP). The resource then applies its local policy to determine the amount of access granted to the community, and further restricts that access based on the policy in the CAS credentials, This serves to limit the user's privileges to the intersection of those granted by the CAS to the user and those granted by the resource provider to the community.

2. Usage scenarios

2.1. Basic procedure for using CAS

A typical CAS user will use only two CAS-specific commands: cas-proxy-init, which contacts a CAS server and obtains a credential, and cas-wrap, which wraps a grid-enabled client program, causing that client program to use the credential that was previously generated using cas-proxy-init. For example, a day in the life of a CAS user might look something like this:

  1. In the morning, the user runs:

    % grid-proxy-init
    % cas-proxy-init -t tag

    The first line generates a Globus proxy credential; the second uses that credential to contact the CAS server and retrieve a CAS credential that includes all the permissions granted to the user by the community. The tag argument can be any string and is used to assign a name for that credential (cas-wrap uses this name to locate the credential).

  2. Several times throughout the day, the user runs commands that look like:

    % cas-wrap -t tag grid-enabled-program args

    This runs the program grid-enabled-program with arguments args, using the CAS credential that had been created by and assigned the name tag.

    For example:

    % cas-wrap -t my-community gsincftp myhost.edu

    looks for a CAS credential with the name "my-community" (e.g., a credential that had been created using "cas-proxy-init -t my-community") and then runs the command "gsincftp myhost.edu", causing the gsincftp program to use that CAS credential to authenticate.

  3. At the end of the day, the user runs:

    % cas-wrap -t tag grid-proxy-destroy

    to destroy the CAS credential, and:

    % grid-proxy-destroy

    to destroy the Globus proxy credential. Or the user might simply let both credentials expire.

3. Command line tools

Please see the CAS Command Reference.

4. Graphical user interfaces

There is no GUI for CAS.

5. Troubleshooting

5.1. Credential Errors

The following are some common problems that may cause clients or servers to report that credentials are invalid:

5.1.1. Your proxy credential may have expired

Use grid-proxy-info to check whether the proxy credential has actually expired. If it has, generate a new proxy with grid-proxy-init.

5.1.2. The system clock on either the local or remote system is wrong

This may cause the server or client to conclude that a credential has expired.

5.1.3. Your end-user certificate may have expired

Use grid-cert-info to check your certificate's expiration date. If it has expired, follow your CA's procedures to get a new one.

5.1.4. The permissions may be wrong on your proxy file

If the permissions on your proxy file are too lax (for example, if others can read your proxy file), Globus Toolkit clients will not use that file to authenticate. You can "fix" this problem by changing the permissions on the file or by destroying it (with grid-proxy-destroy) and creating a new one (with grid-proxy-init). However, it is still possible that someone else has made a copy of that file during the time that the permissions were wrong. In that case, they will be able to impersonate you until the proxy file expires or your permissions or end-user certificate are revoked, whichever happens first.

5.1.5. The permissions may be wrong on your private key file

If the permissions on your end user certificate private key file are too lax (for example, if others can read the file), grid-proxy-init will refuse to create a proxy certificate. You can "fix" this by changing the permissions on the private key file; however, you will still have a much more serious problem: it's possible that someone has made a copy of your private key file. Although this file is encrypted, it is possible that someone will be able to decrypt the private key, at which point they will be able to impersonate you as long as your end user certificate is valid. You should contact your CA to have your end-user certificate revoked and get a new one.

5.1.6. The remote system may not trust your CA

Verify that the remote system is configured to trust the CA that issued your end-entity certificate. See the Administrator's Guide for details.

5.1.7. You may not trust the remote system's CA

Verify that your system is configured to trust the remote CA (or that your environment is set up to trust the remote CA). See the Administrator's Guide for details.

5.1.8. There may be something wrong with the remote service's credentials

It is sometimes difficult to distinguish between errors reported by the remote service regarding your credentials and errors reported by the client interface regarding the remote service's credentials. If you can't find anything wrong with your credentials, check for the same conditions (or ask a remote administrator to do so) on the remote system.

5.2. Some tools to validate certificate setup

5.2.1. Check that the user certificate is valid

openssl verify -CApath /etc/grid-security/certificates
  -purpose sslclient ~/.globus/usercert.pem

5.2.2. Connect to the server using s_clien

openssl s_client -ssl3 -cert ~/.globus/usercert.pem -key ~/.globus/userkey.pem -CApath /etc/grid-security/certificates -connect <host:port>

Here <host:port> denotes the server and port you connect to.

If it prints an error and puts you back at the command prompt, then it typically means that the server has closed the connection, i.e. that the server was not happy with the client's certificate and verification. Check the SSL log on the server.

If the command "hangs" then it has actually opened a telnet style (but secure) socket, and you can "talk" to the server.

You should be able to scroll up and see the subject names of the server's verification chain:

depth=2 /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/CN=ESnet Root CA 1
verify return:1
depth=1 /DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
verify return:1
depth=0 /DC=org/DC=doegrids/OU=Services/CN=wiggum.mcs.anl.gov
verify return:1
    

In this case there were no errors. Errors would give you an extra line next to the subject name of the certificate that caused the error

5.2.3. Check that the server certificate is valid

Requires root login on server.

    openssl verify -CApath /etc/grid-security/certificates -purpose sslserver /etc/grid-security/hostcert.pem

6. Information Regarding CAS Licensing

This version of CAS uses the OASIS Security Assertion Markup Language (SAML) standard. Users should be aware that RSA Security has identified four patents it believes could be relevant to implementing certain operational modes of the SAML specifications. The Globus Alliance has established a license agreement with RSA covering usage of SAML in the Globus Toolkit, however users who redistribute SAML-enabled portions of the Globus Toolkit or use SAML-enabled portions in their own applications should understand the issue and may want to obtain their own royalty-free license from RSA.

For information regarding the patent claims and a royalty-free reciprocal license to the RSA patents, see: http://www.rsasecurity.com/solutions/standards/saml.

For sublicense rights to the RSA patents under the Globus Toolkit Public License, see: Globus Toolkit 4.0 3rd Party Licenses, Copyrights and Disclaimers.