Next: 4 Implementation of the RASSP Configuration and Authorization Management Models
Up: Appnotes Index
Previous:2 The RASSP Configuration Management Model
An authorization is a triplet {oi, rj, tk} where oi is an authorization object in an authorization object hierarchy, rj is a authorization role in an authorization role hierarchy, and tk is an authorization type in an authorization type hierarchy [Rabbitti, 1991]. An authorization object is a data object on which an authorization may be specified. Authorization objects in a database are organized as a directed acyclic graph as shown in figure 3 - 1. An authorization role is a collection of users that have
the same set of authorizations on the same set of objects. The authorization roles in an organization are also organized as a directed acyclic graph as shown in figure 3 - 2. An authorization type is a type of operation that may be performed on a data object. The authorization types for a database are also organized as directed acyclic graphs as shown in figures 3 - 3 and 3 - 4. In figure 3 - 3 the "Grant" authorizations are authorizations to grant an authorization to another role in the role hierarchy. The authorization type hierarchy for projects also contains the "Grant" authorizations, but are not shown in figure 3 - 4 to avoid
cluttering the figure. The directed links between two nodes in a hierarchy represent an implication relationship between the nodes. For example, an authorization for the engineering manager to update design data, implies the authorization to update system definition data, architecture data, etc., as they follow design data in the authorization object hierarchy. The authorization implies the same authorization for the project manager also, as the engineering manager follows project manager in the authorization role hierarchy. Also, since the operation read follows the operation update in the authorization type hierarchy for data objects, the authorization to update design data implies an authorization to read design data as well.
An authorization may be positive, granting an authorization, or negative, revoking an authorization. An explicit or an implicit positive authorization {oi, rj, tk} has to exist for an operation of type tk to be performed by a user belonging to role rj on a data object belonging to the authorization object oi. A positive (or negative) authorization specified on a node ni in an authorization hierarchy may be overridden by a negative (or positive) authorization on a node nj that follows ni in the authorization hierarchy. For example, a positive authorization for a particular role to update design data (in the example authorization
object hierarchy in figure 3 - 1) may be overridden by a negative authorization for the same role to update mechanical design data. Similarly, a positive authorization for the engineering manager (in the example authorization role hierarchy in figure 3 - 2) to update configuration data (in the example authorization object hierarchy in figure 3 - 1) may be overridden by a negative authorization to update waiver data.
The authorization object hierarchy and the authorization role hierarchy for a project may be customized by a RASSP systems administrator. The authorization type hierarchies, however, are not customizable by a RASSP systems administrator. Each authorization type has an associated operation such as checkin, checkout, update etc. Thus, defining a new authorization type will typically involve adding a new functionality to the system.
We describe in this section four sets of mechanisms the data management subsystem of a CAD environment needs to
provide in order to support the RASSP authorization model.
Authorization_Object *create_authorization_object
Creates a new authorization object, as a child of the specified parent authorization object and assigns it the specified name. If no parent authorization object is specified then the root node of a new authorization object hierarchy is created.
void delete_authorization_object
Deletes the subset of the authorization object hierarchy rooted at the specified authorization object, from
the authorization object hierarchy.
void add_child (Authorization_Object *parent,
Adds the sub authorization object hierarchy rooted at the authorization object pointed to by "child" as a child of the specified parent authorization object. A particular sub authorization object hierarchy may be repeated at a number of nodes in an authorization object hierarchy.
void associate_data_file
Associates an existing data file with a node in the authorization object hierarchy. A number of files may be associated with an authorization object. An authorization specified on an authorization object will apply to all the files associated with the authorization object.
Authorization_Object *find_authorization_object
Returns a pointer to an authorization object with the specified name, in the authorization type hierarchy pointed to by "root". If no root is specified, a pointer to a root of an authorization object hierarchy with the specified
name is returned.
Authorization_Object_List get_children
Returns a list of pointers to authorization objects that are children of the specified authorization object.
Authorization_Role *create_authorization_role
Creates a new authorization role, as a child of the specified parent authorization role. If no parent authorization role is specified then the root node of a new authorization role hierarchy is created.
void delete_authorization_role
Deletes the subset of the authorization role hierarchy rooted at the specified authorization role from the authorization role hierarchy.
void add_child (Authorization_Role *parent,
Adds the sub authorization role hierarchy rooted at the authorization role pointed to by "child" as a child of the specified parent authorization role. A particular sub authorization role hierarchy may be repeated at a number of nodes in the authorization role hierarchy.
void associate_user
Associates a user with an authorization role. A number of users may be associated with an authorization role. An authorization specified on an authorization role will apply to all the users associated with the authorization role.
Authorization_Role *find_authorization_role
Returns a pointer to an authorization role with the specified name, in the authorization type hierarchy pointed to by "root". If no root is specified, a pointer to a root of an authorization role hierarchy with the specified name is returned.
Authorization_Role_List get_children
Returns a list of pointers to authorization roles that are children of the specified authorization role.
Authorization_Type *find_authorization_type
Returns a pointer to an authorization type with the specified name, in the authorization type hierarchy pointed to by "root". If no root is specified, a pointer to a root of an authorization type hierarchy with the specified name is returned.
Authorization_Type_List get_children
Returns a list of pointers to authorization types that are children of the specified authorization type.
int grant_authorization
Grants an authorization of type "an_authorization_type" on the object pointed to by "an_authorization_object" to the authorization role pointed to by "an_authorization_role".
int revoke_authorization
Revokes an authorization of type "an_authorization_type" on the object pointed to by "an_authorization_object" from the authorization role pointed to by "an_authorization_role".
3.0 The RASSP Authorization Model
3.1 Authorization Objects, Types, and Roles
3.2 Mechanisms to support the RASSP Authorization Model
3.2.1 Mechanisms to manipulate the authorization object hierarchy
3.2.1.1 Creating an authorization object
(Authorization_Object *parent=0, char *name);
3.2.1.2 Deleting an authorization object
(Authorization_Object *an_authorization_object);
3.2.1.3 Adding a child to an authorization object
Authorization_Object *child);
3.2.1.4 Associating data files with authorization objects
(Authorization_Object *an_authorization_object,
char *file_path_name);
3.2.1.5 Retrieving an authorization object
(Authorization_Object *root=0, char *name);
3.2.1.6 Retrieving the children of an authorization object
(Authorization_Object *an_authorization_object);
3.2.2 Mechanisms to manipulate the authorization role hierarchy
3.2.2.1 Creating an authorization role
(Authorization_Role *parent=0, char *name);
3.2.2.2 Deleting an authorization role
(Authorization_Role *an_authorization_role);
3.2.2.3 Adding a child to an authorization role
Authorization_Role *child);
3.2.2.4 Associating users with authorization roles
(Authorization_Role *an_authorization_role,
char *user_name);3.2.2.5 Retrieving an authorization role
(Authorization_Role *root=0, char *name);
3.2.2.6 Retrieving the children of an authorization role
(Authorization_Role *an_authorization_role);
3.2.3 Mechanisms to manipulate the authorization type hierarchy
3.2.3.1 Retrieving an authorization type
(Authorization_Type *root=0, char *name);
3.2.3.2 Retrieving the children of a node in the authorization type hierarchy
(Authorization_Type *an_authorization_type);
3.2.4 Mechanisms to grant and revoke authorizations
3.2.4.1 Granting authorizations
(Authorization_Object *an_authorization_object,
Authorization_Role *an_authorization_role,
Authorization_Type *an_authorization_type);3.2.4.2 Revoking authorizations
(Authorization_Object *an_authorization_object,
Authorization_Role *an_authorization_role,
Authorization_Type *an_authorization_type);
Next: 4 Implementation of the RASSP Configuration and Authorization Management Models
Up: Appnotes Index
Previous:2 The RASSP Configuration Management Model