- Doc Structure
- A Globus Primer
- Installing GT
- Platform Notes
- Migrating from GT2
- Migrating from GT3
- PDF version
- Best Practices
- Coding Guidelines
- API docs
- Public Interfaces
- Resource Properties
- Performance Studies
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.
The user may access resources that are configured to contact a CAS server using the OGSA-AuthZ service interface. This interface allows the resource to pull down the user's rights from the CAS service and enforce the rights. Refer to Section 3.7, “OGSA-AuthZ Service Interface” for more details.
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 GT 4.1.0 System 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 GT 4.1.0 System 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. Previously, RSA required that users would execute a royalty-free reciprocal license to the RSA patents, and the Globus Alliance had established a license agreement with RSA covering usage of SAML in the Globus Toolkit.
On May 11, 2006, however, RSA issued the following statement:
RSA Intellectual Property Rights Statement In previous correspondence dated December 6, 2004, January 20, 2003 and April 22, 2002, RSA Security Inc. ("RSA") disclosed that it is the assignee of U.S. Patent Nos. 6,085,320 and 6,189,098, both entitled "Client/Server Protocol for Proving Authenticity" and U.S. Patent Nos. 5,922,074 and 6,249,873, both entitled "Method of and Apparatus for Providing Secure Distributed Directory Services and Public Key Infrastructure" (collectively, the "RSA Patents"). At that time, RSA believed that these four patents could be relevant to practicing certain operational modes of the OASIS Security Assertion Markup Language ("SAML") specifications. In the correspondence, RSA offered to grant non-exclusive, royalty-free licenses on a non-discriminatory basis for the RSA Patents. In the interest of encouraging deployment of SAML-based technologies, RSA hereby covenants, free of any royalty, that it will not assert any claims in the RSA Patents which may be essential to the SAML standard v1.0, 1.1 and 2.0 (hereinafter "NECESSARY CLAIMS") against any other entity with respect to any implementation conforming to the SAML standard v1.0, 1.1 and/or 2.0. This covenant shall become null and void with respect to any entity that asserts, either directly or indirectly (e.g., through an affiliate), any patent claims or threatens or initiates any patent infringement suit against RSA and/or its subsidiaries or affiliates. The revocation of the covenant shall extend to all prior use by the entity asserting the claim. RSA will continue to honor existing license agreements for the RSA Patents and will continue to offer as an option to interested third parties the same licensing arrangement described in our previous correspondence. (The license agreement, along with instructions for obtaining and completing the license, are available on RSA's website www.rsasecurity.com)
Please refer to published statement
Users should always check with their legal counsel about the interpretation of the statement, but the statement may indicate that for most SAML-users no execution of any license will be required.