CAS: Server Design
This document is an overview of the CAS server and its
functionality. It is intended to help CAS administrators understand
the features of the current implementation and throws light on
permissions, assertion generation and querying capability in CAS.
The server basically has users, actions and objects and policies
governing the access to the objects for the users to perform specific
actions. To better serve the requirements of a VO, the server allows
grouping of users, actions and objects. This also facilitates
specifiying policies about them with ease. The CAS server can be
thought of as the front-end to a database that maintains state about
such community permissions. The effect of each CAS request is either
to modify this state or query it.
The server has two additional characteristics,
- some query results are signed. Such signed results can be used
for authorization at resources and other policy enforcement points
that acknowledge such credentials.
- the same database is used to maintain information to control
authorization decision for the CAS server.
The CAS database contains a number of tables to store information
about users, resources (objects), actions and policies. This section
describes each of those tables and their contents. The tables are
categorized into tables used to identify and organize users in the
database (trust_anchor, user and user_group), tables used to describe
actions service_type, service_type_action,
service_type_action_groups), tables used to describe and organize
resources or objects (object, object namespace and object_group) and
tables used to describe policies (policy_statement).
Tables relating to users
There are two categories of people in the CAS database, the trust
anchors and the users. The users may further be placed in user groups
and the granularity of operation in the CAS database, with respect to
users, is user group.
Trust anchor table
The trust_anchor table describes authorities that can generate
credentials. It consists of tuples with {trust_anchor_nickname,
authentication_method, authentication_data} tuples. In general, the
meaning of one of these tuples is "database entries that refer to
trust_anchor_nickname apply to the authority represented by
authentication_data for authentication method authentication_method".
The current implementation supports the following contents in these
fields: an authentication_method of "x509" and authentication_data is
the certificate authority's CA certificate.
A trust_anchor_nickname uniquely identifies an
authentication_method and authentication_data across the database.
For example, {globus_ca, x509, <contents of the globus CA
cert> } associates the name globus_ca with the Globus CA
certificate.
User table
The user table consists of {user_nickname, trust_anchor_nickname,
subject_name} tuples, which map raw authentication information into
the symbolic names that appear in CAS user specifications. The
meaning of this tuple is database entries that refer to user_nickname
apply to the user who authenticates as subject_name using the
authentication mechanism and credentials generated by
trust_anchor_nickname.
The current implementation supports a subject_name which is a X509
distinguish name of the user.
A subjectDN and trust anchor nick name uniquely identifies an entry in
the user_table, that is there is a one to one mapping between a user
nickname and the combination of subjectDN and trust anchor nickname.
For example, the tuple {user1, globus_ca, "/O=Globus/CN=User1
Name") means that the person who can authenticate using authentication
method of the trust anchor globus_ca with subject name
"/O=Globus/CN=User1 Name" CA has the permissions assigned to the user
"user1" within the CAS database.
user group table
This table maintains a list of all user groups in the CAS database.
user_group_entry table
The user_group_entry table consists of {group, user} tuples implying
that the specified user is a member of the group.
Tables to relating to actions
The database includes tables related to action
specifications. Different services may define actions that have
similar (or identical) names with different meanings and hence an
action specification must include a service type in addition to the
name of the action. The resource servers that receive CAS policy
statements interpret the service types and actions. For example, a
GridFTP server may honor policy statements that refer to the "file"
service type and ignore policy statements for all other service
types. In theory (because all this processing is done by the resource
servers and not the CAS server), there's no need for the CAS server to
keep track of allowable service types and actions. However, it is
done to make it easier for administrators to detect and avoid errors
while setting permissions.
The server also supports grouping of these service action
mappings. Permissions may be granted to the service action groups or
to a single service action.
Service_type table
This table lists all the service types in the database.
Service_type_action table
The service_type_action table consists of {service_type, action}
tuples implying that the specified action is valid for the specified
service type. For example, a {service_type, action} of {file, read}
means that read is a valid action for the service type file. This
mapping is represents as "serviceType/action" in the current
implementation.
service_action_group
This table lists all the service action group names.
service_action_group_entry
This table contains the following tuple (group, service/action). The
tuple indicates that the service/action belongs to group.
Tables related to resources/objects
An object specification refers to an object or group of objects. An
"object" may itself refer to either a single physical object (e.g., a
file) or a collection of objects (e.g., all files within a
directory). A given object is relevant within a namespace defined and
the properties of the namespace apply to the object.
- namespace_table
This table stores the following tuple (nickname, basename,
comparisonAlg) implying that objects with in the namespace referred to
as nickname in the CAS database are compared using the comparisonAlg
and have a base URL(FIXME explain namespace better, correctly ?) of
basename. A namespace uniquely identifies a single physical
resource. For example, a namespace (ftpNS1, ftp://sample1.org/,
wildcard) implies that all object names within the realm of this
namespace, are to be compared using wildcard matching. Each comparison
algorithm corresponds to a class with in the CAS server implementation
an interface that defines routines for matching objects.
The current implementation supports exact match and wildcard
matching. Objects are represented as "objectNamespace|objectName" in
the current implementation.
- object table
Stores the object name and the namespace that this object is in. For
example, (/mydir/*, ftpNS1) implies that this object is within the
ftpNs1 namespace, described above. Since this has wild card matching
and hence /mydir/foo would match this object.
CAS Objects can be either implicit, that is those that are inherent to
CAS or explicit, that is objects on other resources about which
policies may be stored in the CAS database. While implict objects
maybe of many types, external objects are always represented as type
"object".
- Implicit Objects
It is sometimes convenient to treat some of the entities defined
within the CAS server (such as users and groups) as objects. These
implicit objects can be added to object groups and can appear in
policy statements. Such policy statements govern access permissions to
the CAS database.
The types of implicit objects are:
- A user (a reference to an entry in the user table).This is used
when granting permissions such as "may unenroll this user"
- A user_group (a reference to an entry in the user_group table).
This is used to grant permissions such as "may add users to this
group".
- A service_type (a reference to an entry in the service_type
table). This is used when granting permissions such as "may add
actions to this service type";
- An object_group (a reference to an entry in the object_group
table). This is used when granting permissions such as "may add
objects to this object group".
- A namespace (reference to an entry in namespace table). This is
used when granting permission like "may unenroll this namespace"
- A trust anchor (reference to an entry in the trust_anchor_table);
this is used when granting permissions like "may grant rights on this
trust anchor"
- The CAS server itself; this is used when granting permissions such
as "may add new users to the CAS server". This is added at start up to
the object_table.
- object_group table
This table lists the names of object groups in the database.
- object_group_entry table
The object_group_entry table consists of {object_group,
objectSpecification, objectSpecDesc} tuples; the meaning of this tuple
is that the specified objectSepcification of the type objectSepcDesc
is a member of the specified object group. The objectSpecification
could be an identifier for one of these objectSpecDesc, an
object(implicit or explicit), user, user group, service type,
namespace or trust anchor.
Tables relating to policy statements
The CAS server keeps track of policy statements, which are composed of
three parts: a user specification, which denotes a user or set of
users, an action specification, which denotes an operation (e.g., read
a file) or a group of operation, and an object specification, which
specifies an object or group of objects.
For example, if we were to specify a policy statement as an English
sentence, "User1 may read ftp://myhost.edu/myfile", then the user
specification would be "User1", the action specification would be
"file/read", and the object specification would be
ftp://myhost.edu/myfile. In reality, the CAS server maintains this
information as entries in database tables and translates it into a
policy language when responding to a query.
- policy_statement table
The policy_statement table consists of (userGroup, actionSpec,
actionSpecDesc, objectSpec, objectSpecDesc) corresponding to policy
statement that implies
- userGroup - a reference to an entry in user_group table
- actionSpec - a reference to an entry in service_action table or
service_action_group table
- actionSpecDesc - either "serviceAction" or "serviceActionGroup"
describing the actionSpec entry
- objectSpec - a reference to an entry in object table,
object_group_entry table, user table, user_group table, service_type
table, namespace table or trust_anchor table.
- objectSpecDesc - either "object", "objectGroup", "user",
"userGroup", "serviceType", "namespace" or "trustAnchor" describing
the objectSpec entry.
Each statement implies that users who belong to the userGroup are
permitted to perform the service/action or all service/action(s) in
the serviceActionGroup on the specified object or all objects in the
said object group.
A user (U) is said to have permission to perform service/action S/A on
object (O) if there is a statement in the policy_statement table that
meets these three conditions:
- The user element applies: U appears in the user table and the user
element is either:
- a user_group_specification referring to a user_group containing U, or
- the community_specification.
- The action element applies:
- the action specification refers to service_type S and the action A.
- the action specification refers to a service_action group that has
service type S and action A as a member.
- the action specification is superuser.
- The object element applies: it's either:
- An object that "matches" O - that is, the appropriate matching
function (based on the namespace that the object belongs to) applied
to O and the object_name yields a match, or
- An object group that contains an object that "matches" O.
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.
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.
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.
- The applicable user is identified as described here.
- Applicable set of policy statements for the user are identified as
described here.
- If the set is not empty, policy assertion is created or else null
is returned.
- 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.
- 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.
- 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 methods for the requests are:
- getMaximalAssertion : This is a self request and any user in the
CAS database can make this request. The set of policy statements is
the complete set of the user's permissions, for all services other
than the CAS service.
- getUserAssertion : In this case, an additional argument specifies
the requested user; the set of policy statements is the complete set
of that user's permissions for all services other than the CAS
service. This request requires cas/query or cas/superuser permission
on the cas/server object.
- getAssertion : This is a self-request and any user in the CAS
database is allowed to make this request. In this case, the list of
{service/action, object} permissions is determined as follows:
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 maximal assertion and
user assertion generation, 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
(FIXME: Add implementation specifics: database module design, front end
OGSA service design. describe setup and such.)
- CASService runs in some user hosting enviroment.
- It need not be run as root.
- Run in some account - server-config and such shld not be accessible
to other users since it has db user name and password.
- Only the owner of the service (casAdmin) is allowed access to the
database.
- Any user in the grid map should be able to invoke methods on the service.
- At startup, the user's data is read from config and the table is
populated as follows
- ServiceTypeAction is returned as serviceType/Action (permission
query looks for first occurance of slash)
- SAMLAssertion authorize(SAMLAuthzQuery)
SAMLAuthzQuery:
SAMLSubject
String name (required) : subjectDN
String nameQualifier : DN of the CA
String format : #X509SubjectName
Collection confMethod
: urn:oasis:names:tc:SAML:1.0:am:X509-PKI
String confData
Element keyInfo
String resource : object
Collection (SAMLActions)
String namespace : serviceType
String actionName : actionName
SAMLAssertion:
String issuer (required) : DN of the server
Date notBefore : current time stamp
Date onOrAfter : if lifetime <= 0, server lifetime
else min(requested lifetime,
server lifetime)
Collection (Conditions)
SAMLAdvice
Collection (SAMLStatment)
- SAMLAuthzDecisionStmt
SAMLSubject
(As in SAMLAuthzQuery)
String resource : object
String decision : permit
Collection (SAMLActions)
Namespace : service type
ActioName : action name
Collection (SAMLEvidence)
MajorVersion : 1
MinorVersion : 0
AssertionID : Unique Id (Generated by OpenSAML)
Issuer instant : Current time
Rework of Object storage
Assume user U wants to add the object O. For this to succeed,
the equality, superset test and the subset test have to succeed.
Exact match
No exact match is found.
Superset test:
Either:
There is some object S such that:
S is a superset of O, and
U has cas/enrollObject permissions on S
or
There is no object in the database that is a superset of O, and
U has cas/enrollObject permissions on casServer
Subset test
For every object S in the database that is a subset of O,
U has cas/grantAll permissions on S
Updated: 07 - 24 - 2003