next up previous contents
Next: 4 Implementation of the RASSP Configuration and Authorization Management Models Up: Appnotes Index Previous:2 The RASSP Configuration Management Model

RASSP Information Management Appnote

3.0 The RASSP Authorization Model

3.1 Authorization Objects, Types, and Roles

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.

Figure 3 - 1: An Example Authorization Object Hierarchy

Figure 3 - 2: An Example Authorization Role Hierarchy

Figure 3 - 3: The Authorization Type Hierarchy for Design Objects

Figure 3 - 4: The Authorization Type Hierarchy for Projects

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.

3.2 Mechanisms to support the RASSP Authorization Model

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.

3.2.1 Mechanisms to manipulate the authorization object hierarchy

3.2.1.1 Creating an authorization object

  Authorization_Object *create_authorization_object
    (Authorization_Object *parent=0, char *name);

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.

3.2.1.2 Deleting an authorization object

  void delete_authorization_object
    (Authorization_Object *an_authorization_object);

Deletes the subset of the authorization object hierarchy rooted at the specified authorization object, from the authorization object hierarchy.

3.2.1.3 Adding a child to an authorization object

  void add_child (Authorization_Object *parent,
      Authorization_Object *child);

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.

3.2.1.4 Associating data files with authorization objects

  void associate_data_file
    (Authorization_Object *an_authorization_object,
    char *file_path_name);

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.

3.2.1.5 Retrieving an authorization object

  Authorization_Object *find_authorization_object
    (Authorization_Object *root=0, char *name);

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.

3.2.1.6 Retrieving the children of an authorization object

  Authorization_Object_List get_children
    (Authorization_Object *an_authorization_object);

Returns a list of pointers to authorization objects that are children of the specified authorization object.

3.2.2 Mechanisms to manipulate the authorization role hierarchy

3.2.2.1 Creating an authorization role

  Authorization_Role *create_authorization_role
    (Authorization_Role *parent=0, char *name);

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.

3.2.2.2 Deleting an authorization role

  void delete_authorization_role
    (Authorization_Role *an_authorization_role);

Deletes the subset of the authorization role hierarchy rooted at the specified authorization role from the authorization role hierarchy.

3.2.2.3 Adding a child to an authorization role

  void add_child (Authorization_Role *parent,
    Authorization_Role *child);

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.

3.2.2.4 Associating users with authorization roles

  void associate_user
    (Authorization_Role *an_authorization_role,
    char *user_name);

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.

3.2.2.5 Retrieving an authorization role

  Authorization_Role *find_authorization_role
    (Authorization_Role *root=0, char *name);

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.

3.2.2.6 Retrieving the children of an authorization role

  Authorization_Role_List get_children
    (Authorization_Role *an_authorization_role);

Returns a list of pointers to authorization roles that are children of the specified authorization role.

3.2.3 Mechanisms to manipulate the authorization type hierarchy

3.2.3.1 Retrieving an authorization type

  Authorization_Type *find_authorization_type
    (Authorization_Type *root=0, char *name);

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.

3.2.3.2 Retrieving the children of a node in the authorization type hierarchy

  Authorization_Type_List get_children
    (Authorization_Type *an_authorization_type);

Returns a list of pointers to authorization types that are children of the specified authorization type.

3.2.4 Mechanisms to grant and revoke authorizations

3.2.4.1 Granting authorizations

  int grant_authorization
    (Authorization_Object *an_authorization_object,
    Authorization_Role *an_authorization_role,
    Authorization_Type *an_authorization_type);

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

3.2.4.2 Revoking authorizations

  int revoke_authorization
    (Authorization_Object *an_authorization_object,
    Authorization_Role *an_authorization_role,
    Authorization_Type *an_authorization_type);

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


next up previous contents
Next: 4 Implementation of the RASSP Configuration and Authorization Management Models Up: Appnotes Index Previous:2 The RASSP Configuration Management Model

Approved for Public Release; Distribution Unlimited Dennis Basara