Table of Contents
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).
- 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.
- 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).
- 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.
- 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.
- 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.
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:
In the morning, the user runs:
% grid-proxy-init % cas-proxy-init -t
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
tagargument can be any string and is used to assign a name for that credential (cas-wrap uses this name to locate the credential).
Several times throughout the day, the user runs commands that look like:
% cas-wrap -t
This runs the program grid-enabled-program with arguments
args, using the CAS credential that had been created by and assigned the name
% 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.
At the end of the day, the user runs:
% cas-wrap -t tag grid-proxy-destroy
to destroy the CAS credential, and:
to destroy the Globus proxy credential. Or the user might simply let both credentials expire.
Please see the CAS Command Reference.
The following are some common problems that may cause clients or servers to report that credentials are invalid:
Use grid-proxy-info to check whether the proxy credential has actually expired. If it has, generate a new proxy with grid-proxy-init.
This may cause the server or client to conclude that a credential has 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.
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.
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.
Verify that the remote system is configured to trust the CA that issued your end-entity certificate. See the Administrator's Guide for details.
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.
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.
openssl verify -CApath /etc/grid-security/certificates -purpose sslclient ~/.globus/usercert.pem
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
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.