CAS: Developer's Guide

Overview
APIs
Database Design
>CAS Requests
Permissions

CAS Requests

CAS requests can be broadly classified into administrative requests and query requests. Each CAS request requires some set of permissions. These permission are assessed by looking up the authenticated user in the user table, (to get the CAS nickname mapped to this user) and using that to check if the policy table has a permission defined for the operation as described in the previous section.

This page contains the following topics:

• CAS Administrative Requests
• CAS Query Requests

CAS Administrative Requests

Administrative requests typically modify the database and are used to add or remove CAS table entries.

• Enroll or unenroll trust anchor
• Enroll or unenroll user
• Create or delete namespace
• Create or delete objects
• Create or delete service type
• Add or remove service type/action mappings
• Create or delete user, object or service action groups
• Add or remove entries from any of the above
• defined groups
• grant or revoke permissions

The above request asserts permissions and performs the operation preserving the database consistency. For example, a policy can be defined (or right can be granted) only on objects that exist in the CAS database and so on.

Creation of any CAS object (like a trust anchor, namespace, object, user, service type, user group, object group, service_action group), allows the client to choose a user group, (irrespective of whether the client belongs to the group or not), to which all permissions on the newly created object is granted. In the case of the operation where the user creates a new user group, if the client chooses to grant all permissions to the newly created user group, then the user is added to the new group.

CAS Query Requests

Query request are classified into:

• requests that return assertions that are typically signed and can be used by the client to authorize with some resource.
• requests that return information about the current state of the CAS database.

Assertion requests

The CAS server supports requests to retrieve policy information as signed policy assertion. These assertions can be presented at a resource by the client for authorization purposes. A policy assertion includes a list of policy statements, the distinguished name of the user that the permissions apply to, a validity period (a start and end time corresponding to when the assertion is valid), and is signed by the CAS server. Each of the requests for policy assertions takes a lifetime argument (the desired lifetime of the policy assertion, in seconds) and the following is done to generate them.

1. The applicable user is identified as described here .
2. Applicable set of policy statements for the user are identified as described here .
3. If the set is not empty, policy assertion is created or else null is returned.
4. The assertion lifetime is calculated as follows. If the requested lifetime is 0, the server's default lifetime is used, otherwise, the minimum of the requested lifetime and the server's maximum lifetime is used.
5. The list of {service/action, object} permissions, the validity time (start time is the current time, end time is the current time plus the assertion lifetime), and the applicable user's subject name is formatted into a assertion.
6. The assertion is signed and returned to the requestor.

In the current implementation, Security Assertion Markup Language (SAML), standard defined by OASIS , is used for exchange of request for authorization assertions and response. OpenSAML , an open source implementation of the SAML 1.0 specification has been used as a utility to generate and process SAML Queries and Assertions.

The "getAssertion" method with right parameters maybe used for these requests.For each requested permission, if there is a policy statement granting the request in the CAS database, then the requested (service/action, object) is added to the returned assertion as a decision statement.

Assertion generation is done based primarily based on the objects. This has implications in the case of a requests where all applicable polices are returned. The service restricts polices only based on objects and does not make a distinction on the service type. For example, if a non-implicit object has a CAS service type policy on it, that will be returned as a part of the assertion. Might be useful in case some other CAS server itself being treated as an external resource and the cas service types are used)

Non-assertion queries

These are requests that can be used to query the CAS service for information. Some of the queries supported are:

• List of all CAS Objects of a give type. E.g. list of all users.
• User's nickname which returns the CAS nickname of the person making the query
• List of all members of a given group. E.g. list of all members of user group foo.
• List of all policies for a given CAS Object. E.g. list of all policies on a user name foobar.
• Details about a given CAS object. E.g. Details about user foo would include the user nickname, subject name, trust anchor and groups the user belongs to.