GT 3.9.5 CAS: User's Guide

Introduction

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).

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. gridmap files and disk quotas, filesystem 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.

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.

Command-line tools


CAS User Clients

These are clients that a user would use to get a signed CAS assertion and have it embedded in the user proxy. A script is also provided for the user to use the proxy with the CAS assertion to run arbitraty command.

cas-proxy-init

cas-proxy-init contacts a CAS server and obtains a CAS credential for the user to be used to access CAS-enabled services.
        cas-proxy-init [options] [ -t tag | -p proxyfile ]
where

-p proxyfile

Specific the file in which to store the CAS credential. Cannot be used with the -t option.

-t tag

Choose a filename in which to store the CAS credential based on the value tag. Cannot be used with the -p option.

-c url

Contact URL for the CAS server. This typically looks like,

    http://Host:Port/ogsa/services/base/cas/CASService
  
where Host and Port are host and port where container with CAS service is running.

-s server_identity

When doing mutual authentication with the CAS server, expect server_identity as the remote identity.

-f policy_file

Generate a CAS credential that includes only those permissions specified in file policy_file (the default is to generate a credential with all the userŐs permissions).

-l hours

Generate a credential that will time out after hours hours. This is a request for lifetime, but the CAS server may have a set maximum for the assertion lifetime which will be enforced.

-m messageType

Used to set the chosen security mechanism. It can be set to 'msg' for Secure Message, 'conv' for Secure Conversation and 'trans' for Transport security. If not set and the server URL starts with 'https', Transport Security is used, else Secure Message is used.

-n protectionType

Used to set the protection type required with the security mechanism. Can be set to 'sig' or 'enc' to indicate signature or encryption. Defaults to signature.
Getting specific CAS rights using cas-proxy-init

It is possible to request specific permissions from the CAS server using the -f option. This option causes cas-proxy-init to read a set of requested rights from a file.

This file should contain one or more resource identifiers:


        Resource: ResourceNamesapce|ResourceName 

For each resource, one or more actions identifers:

        serviceType action 

For example, if the client needed assertions for "file/read" service/action for resource "ftp://sample.org" and "ftp://sample3.org", both in "FTPNamespace" and "directory/read" and "directory/write" permissions on the former resource only, the policy file should have the following entries:

        Resource: FTPNamespace|ftp://sample1.org
        file read
        directory read
        directory write
        Resource: FTPNamespace|ftp://sample3.org
        file read

To indicate any resource, the following wildcard notation should be used.

uri:samlResourceWildcard

To indicate any action, the following wildcard notation for serviceType and action should be used. Note that this should be the first (and clearly the only action) in the list of action specified. All other actions in the list are ignored and if it is not the first, it is not treated as wildcard.

uri:samlActionNSWildcard uri:samlActionWildcard

For example, if the client needs assertions for all resources and all actions the policy file should look like.

       Resource: uri:samlResourceWildcard
       uri:samlActionNSWildcard uri:samlActionWildcard

If the client needs assertions for all actions on resource "FTPNamespace|ftp://sample1.org", the policy file should be as follows

       Resource: FTPNamespace|ftp://sample1.org
       uri:samlActionNSWildcard uri:samlActionWildcard

cas-wrap

The cas-wrap program runs a grid-enabled program, causing it to use previously-generated CAS credentials.

        cas-wrap [-t tag | -p proxyfile ] command args

cas-wrap invokes the given command with the given argument using the specified previously-generated CAS credential. For example:

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

will look for a credential generated by a previous execution of:

        % cas-proxy-init -t my-community

and then set the environment to use that credential while running the command

        % gsincftp myhost.edu

The second form should be used if cas-proxy-init was run with the -p option; for example,

        % cas-wrap -p /path/to/my/cas/credential gsincftp myhost.edu

will look for a credential generated by a previous execution of:

        % cas-proxy-init -p /path/to/my/cas/credential

and then set the environment to use that credential while running the command

        % gsincftp myhost.edu

CAS Administrator Clients

The CAS administrator clients can be used to manipulate and maintain the data in CAS database. It allows one to enroll (and unenroll) CAS Objects, create (and delete) groups, add (and remove) members from groups, add (and remove) service type and action mappings. Typically these operation are performed by the CAS Administrator.

All enroll operations involve granting cas/grantAll permission on the enrolled object to some user group (to which the user may belong to or otherwise).

All operations require that the user have specific permissions to perform the operation. Permissions and policies are given and applied to user groups. Hence a user is said to have permission to perform an operation if one of the user groups that the user belongs to has permission to perform that operation.

If some user group to which the user belongs to, has permission "superuser" on cas server object, then they may perform any operation, even if they donot have specific rights that are outlined below for each operation.

If a user has cas/grantAll permission on any object, then the user is permitted to perform any operations on that object.

Enrolling and Unenrolling Trust Anchors

To enroll a trust anchor, the user must have cas/enroll_trustAnchor permission on that cas server object(that is, must have permission to perform the enroll_trustAnchor action on the cas service type). The enroll operation allows the user to choose a user group to which cas/grantAll permission on the enrolled object should be granted. The nickname should be unique across the CAS database and is used to refer to this trust anchor.

  casAdmin$ cas-enroll [options] trustAnchor userGpName nickname authMethod authData

where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • nickname : trust anchor nickname
  • authMethod : authentication method used by the trust anchor
  • authData : data used for authentication, typically the DN

To unenroll a trust anchor, the user must have cas/unenroll permission on that trust anchor. The trust anchor must also be unused, that is there may not be any users in the database that have this trust anchor or it may not be a part of any object group.

  casAdmin$ cas-remove [options] trustAnchor nickname
where:
  • options : client options
  • nickname : nickname of the trust anchor to be unenrolled

If the trust anchor nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that trust anchor is purged.

Enrolling and Unenrolling Users

To enroll a user, the user must have cas/enroll_user permission (that is, must have permission to perform the enroll_user action on the cas service type). The enroll operation allows the user to choose a user group to which cas/grantAll permission on the enrolled object should be granted. The enrolled user also gets all the privileges granted to the community. The nickname should be unique across the CAS database and is used to refer to this user.

  casAdmin$ cas-enroll [options] user userGpName nickname subjectName trustAnchorNick

where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • nickname : user nickname
  • subjectName: subject name from the user's credentails.
  • trustAnchorNick: Name of the user's trust anchor. (Must exist in the CAS database)

To unenroll a user, the user must have cas/unenroll permission on that user. The user must also be unused, that is, there may not be any user groups in the database that have this user as a member.

  casAdmin$ cas-remove [options] 
	  user nickname
where:
  • options : client options
  • nickname : nickname of the user to be unenrolled

If the user nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that user is purged.

Enrolling and Unenrolling Namespaces

To enroll a namespace, the user must have cas/enroll_namespace permission (that is, must have permission to perform the enroll_namespace action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled object. The comparison algorithm specified should be the name of the Comparison class that needs to be used to compare objects that belong to this namespace. The nickname should be unique across the CAS database and is used to refer to this user.

casAdmin$ cas-enroll [options] namespace userGpName nickname basename comparisonAlg

where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • nickname : namespace nickname
  • basename : base URL for the name space
  • comparisonAlg : Comparison algorithm to be used. Unless the standard comparison algorithms described below are used, the fully qualified name of the class that needs to be used should be given. The class needs to extend from the abstract class org.globus.ogsa.impl.base.cas.server.ObjectComparison.
The two comparison classes provided as a part of the distribution are
  • ExactComparison : This class does a case-sensitive exact comparison of the object names. If comparisonAlg in the above method is set to "ExactComparison", the class in the distribution is loaded and used.
  • WildcardComparison: This class does wild card matching as described in "CAS Simple Policy Language". (FIXME link to that doc) It assumes that the wild card character is "*" and "/" is file separator. If comparisonAlg in the above method is set to "WildCardComparison", the class in the distribution is loaded and used.

Also two namespaces are added to the CAS database at bootup time, other than the inherent CAS Namespace.

  • FTPDirectoryTree : Uses the WildCardComparison Algorithm and has the base URL set to current directory.
  • FTPExact : Uses the ExactComparison Algorithm and has the base URL set to current directory.

To unenroll a namespace, the user must have cas/unenroll permission on that namespace. The namespace must also be unused, that is, there may not be any object in the database that belongs to this namespace.

  casAdmin$ cas-remove [options] namespace nickname

where:
  • options : client options
  • nickname : nickname of the namespace to be unenrolled

If the namespace nickname specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that namespace is purged.

Enrolling and Unenrolling Objects

To enroll a object, the user must have cas/enroll_object permission (that is, must have permission to perform the enroll_object action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled object. The name of the object and the the namespace this object belongs to identifies an object in the database and should be unique across the CAS database.

  casAdmin$ cas-enroll [options] object userGpName objectName namespaceNick
where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • objectName : name of the object
  • namespaceNick: nickname of the namespace this object belongs to.

To unenroll a object, the user must have cas/unenroll permission on that object. The object must also be unused, that is, there may not be any object group in the database that this object belongs to

casAdmin$ cas-remove [options] object objName namespaceNick

where:
  • options : client options
  • objName : name of the object to be unenrolled
  • namespaceNick: nickname of the namespace this object belongs to

If the object specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that object is purged.

Enrolling and Unenrolling Service Type

To enroll a service type, the user must have cas/enroll_serviceType permission (that is, must have permission to perform the enroll_serviceType action on the cas service type). The enroll operation allows the user to choose a userGroup to have cas/grantAll permission on the enrolled service type. The service type name should be unique across the CAS database.

  casAdmin$ cas-enroll [options] serviceType userGpName serviceTypeName
where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • serviceTypeName: service type name

To unenroll a service type, the user must have cas/unenroll permission on that service type. The service type must also be unused, that is, there may not have any service type to action mapping.

  casAdmin$ cas-remove [options] serviceType serviceTypeName

where:

If the service type specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that service type is purged.

Maintaining Service Types

To add an action mapping to a service type, the user must have cas/create_group_entry permission on the service type.

  casAdmin$ cas-action [options] add serviceTypeName actionName
where:
  • options : client options
  • serviceTypeName: service type name
  • actionName: action name

To remove a service type action mapping, the user must have cas/delete_group_entry permission on the service type.

  casAdmin$ cas-action [options] remove serviceTypeName actionName

where:
  • options : client options
  • serviceTypeName: service type name
  • actionName: action name

If the group member being removed does not exist, an error is not thrown.

Maintaining User Groups

To create a new user group, the user must have cas/create_user_group permission(thats is, must have permission to perform create_user_group action on cas service type). The user group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created user group. If the user group that is chosen to have cas/grantAll permission is the new group created, then the user making this request is added to the new group.

  casAdmin$ cas-group-admin [options] user create userGpName groupName
where :
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • groupName : name of the user group being created

To add to a user to a user group, the user must have cas/add_group_entry permission on that particular user group. Only user nicknames that exist in the CAS database can be valid members.

  casAdmin$ cas-group-add-entry [options] user groupName nickname
where:
  • options : client options
  • groupName : user group name to which the memeber needs to be added
  • nickname : nickname of the user to be added to this group.

To remove a user from a user group, the user must have cas/remove_group_entry permission on that particular user group.

  casAdmin$ cas-group-remove-entry [options] user groupName nickname

where:
  • options : client options
  • groupName : user group name to which the memeber needs to be added
  • nickname : nickname of the user to be added to this group.

If the group member being removed does not exist, an error is not thrown.

To delete a user group, the user must have cas/delete_user_group entry permission on that user group. The group must be empty and also not be referenced from other entities in the database(for example should not be a memeber of some object group and such).

  casAdmin$ cas-group-admin [options] user delete groupName
where:
  • options : client options
  • groupName : name of the user group to be deleted

If the user group specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that user group is purged.

Maintaining Object Groups

To create a new object group, the user must have cas/create_object_group permission(thats is, must have permission to perform create_object_group action on cas service type). The object group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created object group.

  casAdmin$ cas-group-admin [options] object create userGpName groupName
where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • groupName : name of the user group being created

To add to a member, (an object group can have the following CasObjects as members, object, user, user group, service type, namespace or trust anchor) to a object group, the user must have cas/add_group_entry permission on that particular object group.

  casAdmin$ cas-group-add-entry [options] object groupName objectSpecDesc objcetSpec

where:
  • options : client options
  • groupName : object group name to which the memeber needs to be added
  • objectSpecDesc: type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) service Type)
  • objectSpec : the identifier for the CasObject the user is adding (nickname (or) nickname (or) groupName (or) objectNamespace objectName (or) nickname (or) serviceTypeName)

To remove an object from a object group, the user must have cas/remove_group_entry permission on that particular object group:

  casAdmin$ cas-group-remove-entry [options] object groupName objectSpec objectSpecDesc

where
  • options : client options
  • groupName : user group name to which the memeber needs to be added
  • objectSpecDesc: type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) service Type
  • objectSpec : the identifier for the CasObject the user is adding (nickname (or) nickname (or) groupName (or) objectNamespace objectName (or) nickname (or) serviceTypeName)

If the group member being removed does not exist, an error is not thrown.

To delete a object group, the user must have cas/delete_user_group entry permission on that object group. The group must be empty.

  casAdmin$ cas-group-admin [options] object delete groupName
where:
  • options : client options
  • groupName : name of the object group to be deleted

If the object group specified does not exist, an error is not be thrown. If the unenroll operation is successfull all policy data on that user group is purged.

Maintaining Service/Action Groups

To create a new service/action group, the user must have cas/create_serviceAction_group permission(that is, must have permission to perform create_serviceAction_group action on cas service type). The serviceAction group name should be unique across the CAS database. The create operation allows the user to choose a user group to have cas/grantAll permission on the created serviceAction group.

  casAdmin$ cas-group-admin [options] serviceAction create userGpName groupName
where:
  • options : client options
  • userGpName : the user group to which cas/grantAll permission should be granted on this trust anchor entity
  • groupName : name of the serviceAction group being created

To add to a service/Action to a serviceAction group, the user must have cas/add_group_entry permission on that particular serviceAction group (that is, must have permission to perform add_group_entry action on that service action group)

  casAdmin$ cas-group-add-entry [options] serviceAction groupName serviceTypeName actionName

where
  • options : client options
  • groupName : user group name to which the member needs to be added
  • serviceTypeName : service type name part of mapping to be added to group
  • actionName : action name part of mapping to be added to group

To remove a service/Action from a serviceAction group, the user must have cas/remove_group_entry permission on that particular serviceAction group.

  casAdmin$ cas-group-remove-entry [options] serviceAction groupName serviceTypeName actionName

where:
  • options : client options
  • groupName : user group name to which the memeber needs to be added
  • serviceTypeName : service type name part of mapping to be added to group
  • actionName : action name part of mapping to be added to group
If the action being removed does not exist, an error is not thrown.

To delete a serviceAction group, the user must have cas/delete_user_group entry permission on that serviceAction group. The group must be empty and also must not be referenced from any other entity in the database. (for example should not be a memeber of some object group and such)

  casAdmin$ cas-group-admin [options] serviceAction delete groupName
where:
  • options : client options
  • groupName : name of the user group to be deleted

If the service action group specified does not exist, an error is not thrown. If the unenroll operation is successfull all policy data on that serviceAction group is purged.

Maintaining Permissions

The user may grant permissions to a user group, on a object or object group to perform a service action or service action group (that is to perform any action that is a member of the service action group to which permission is granted), provided the user has has both:

  • cas/grant permission on the object or object group
  • permission to perform the service action or service action group on the object or object group.
  casAdmin$ cas-rights-admin [options] grant userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec
where:
  • options : client options
  • userGroupName : the user group to grant permission for.
  • objectSpec : identifier for object or object group
  • objectSpecDesc : type (object or objectGroup)
  • actionSpec : identifier for action or action group
  • actionSpecDesc : type (serviceAction or serviceActionGp)

The user may revoke a policy in the CAS database provided the user has cas/revoke permission on the object or object group on whch the policy is defined.

  casAdmin$ cas-rights-admin [options] revoke userGroupName  objectSpecDesc objectSpec  actionSpecDesc actionSpec
where:
  • options : client options
  • userGroupName : the user group to grant permission for.
  • objectSpecDesc: type of CasObject (trustAnchor (or) user (or) userGroup (or) object (or) namespace (or) serviceType (or) userGroup (or)
  • objectSpec : identifier for object or object group
  • actionSpec : identifier for action or action group
  • actionSpecDesc : type (serviceAction or serviceActionGp)

CAS Query Clients

The CAS Query commands donot alter the state of the database and any CAS user who has cas/query permissions may use the commands to retrieve data from the CAS server.

The following queries can be run against the CAS server. These are typically used by CAS clients (who may not be administrators).

The user need cas/query permissions to perform these operations, that is the user must have permission to query on the cas server object.

Getting user's CAS identity

  casUser$ cas-whoami [options]
where Returns the CAS user nick of the client.

Getting object list

  casUser$ cas-list-object [options] type
where
  • options : client options
  • type : trustAnchor (or) user (or) userGroup (or) object (or) objectGroup (or) objectGroup (or) namespace (or) serviceType (or) serviceAction (or) serviceActionGp
Returns a list of CasObjects in the database of the requested type.

Getting CAS object

  casUser$ cas-get-object [options] type name

where
  • options : client options
  • type : trustAnchor (or) user (or) object (or) namespace (or) service Type
  • name : nickname (or) nickname (or) objectNamesapce objectName (or) nickname (or) serviceTypeName (corresponding to the type)
Returns the particular object of the said type and name.

Getting group memebers


  casUser$ cas-group-list-entries [options] type name
where
  • options : client options
  • type : Type of group. user (or) object (or) serviceAction
  • name : Name of group
Returns list of group members.

Getting policy information

  casUser$ cas-find-policies [-c cas-url] type name
where
  • [-c cas-url] : the URL of the CAS service
  • type : trustAnchor (or) user (or) userGroup (or) object (or) objectGroup (or) namespace (or) service Type (or) serviceAction (or) serviceActionGroup
  • name : nickname (or) nickname (or) groupName (or) objectNamespace|objectName (or) groupName (or) nickname (or) serviceTypeName (or) serviceType/Action (or) groupName (corresponding to the type)
Returns all applicable policies, both policies that are implicit to the CAS server and those that are external.

CAS Client common options

The options that are common to all clients are
 [-debug -help -v -c cas-url -s server-identity -m mechanism -p protection] 
  • CAS Service URL: The -c cas-url option can be used to set CAS Service instance, where cas-url is the URL of the CAS service instance. Alternatively, an environment variable can be set as shown here.

    The instance URL typically looks like http://Host:Port/ogsa/services/base/cas/CASService, where Host and Port are host and port where container with CAS service is running.

  • CAS Service Identity:

    The -s server-identity option can be used to set the expected CAS server identity, where server-identity is the identity of the CAS service. Alternatively, an environment variable can be set as shown here. If neither is set, host authorization is done and the expected server credential is cas/<fqdn>, where <fqdn> is the fully qualified domain name of the host on which the CAS service is up.

  • Debug: To run the client with debug message traces and error stack traces, -debug flag must be used
  • Usage: The -help flag prints the usage message for the client.
  • Version number: The -v flag prints the version number.
  • Security Mechanism: The -m flag is used to set the chosen security mechanism. It can be set to 'msg' for Secure Message, 'conv' for Secure Conversation and 'trans' for Transport security. If not set and the server URL starts with 'https', Transport Security is used, else Secure Message is used.
  • Protection type: The -p flag is used to set the protection type required with the security mechanism. Can be set to 'sig' or 'enc' to indicate signature or encryption. Defaults to signature.
Note: If you have a asterix (*) in your command, you might have to escape it with backslash.

Graphical user interfaces

There is no GUI for CAS.

Troubleshooting

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

Your proxy credential may have expired

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

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.

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.

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.

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.

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 [TODO: add admin guide link] for details.

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 [TODO: add admin guide link] for details.

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.

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 a 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: http://www.globus.org/toolkit/legal/4.0/licenses4.html#RSA