User's Manual

Chapter 3.
WAF Component: Kernel
This chapter discusses the kernel layer, which provides services used by several parts of the WAF
system. This component was initially explained in Section 1.2.1 Kernel. This discussion focuses on
the various parts of the kernel component which a developer will need in building for WAF.
For information on how to utilize the kernel in WAF applications, see Chapter 10 Kernel Tutorial.
3.1. Users and Groups
Applications have users. A user is a person who uses an application to accomplish some purpose.
In order to serve the needs of users, applications store information about the users. This information
is used to personalize content, check the permission of a user initiated operation, and to provide
information about a user to other users.
Users are organized into groups. The users in a groups are said to be members of the group. Groups
can also be members of groups. A group exists so that several users and groups can be collectively
identified as an entity.
Groups and users are the two types of parties. This parties system is one of the pieces of the kernel.
The ability to refer to an entity that may be a group or a user provides flexibility to application authors
in writing data models. An example is the definition of a group itself: 1 or more parties. This definition
is recursive, but that recursion reflects the flexibility of having a party type.
3.2. ACSObject
Party, Group, and User are all subtypes of ACSObject. Its purpose is to serve as a base class for use
in common object-level services, such as categorization and permissioning. As such, subclasses are
often types that users directly interact with such as Workflow or Category. The ACSObject object
type also has generic attributes such as a unique id and a displayName.
The ACSObject object type and class are abstract. In order to differentiate among subtypes there are
attributes objectType and defaultDomainClass. These attributes are used to instantiate the appropriate
Java domain class to wrap data objects that are instances of subtypes of ACSObject.
3.3. Permissions
The goal of the permissions system is to provide generic means to both programmers and site admin-
istrators to check, grant, or revoke permissions via a consistent interface. For example, an application
developer might decide that viewing a certain set of pages within the application is an operation to be
individually granted or revoked from a user. It’s expected that the permissions system will be heavily
used in production - almost every page will make at least one permissions API call, and some will
make several.
The permissions systems deals with three kinds of objects: ACSObject, Party, Privilege. The
system maintains a set of grants of the form Party p has Privilege priv on ACSObject obj. The
privileges represent actions that are performed on objects.
There are generic privileges that are always defined: read, write, edit, admin, create, and
delete. In addition, applications can define custom privileges, for example categorize.
The permissions system is used to answer questions such as: