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.

2. 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:

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).
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.
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. Using Authorization Service Interface

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 7, “OGSA-AuthZ Service Interface” for more details.

Prev		Next
GT 4.1.3 CAS User's Guide	Home	Admin Commands