Hierarchical Security (Overview)

Hierarchical security enables you to assign roles access to domain, application, or functional role tasks in one step. The roles can then be assigned to users. This makes it possible for large numbers of schema elements (e.g. fields, tasks) to be aggregated according to function. It also means that these aggregates can be assigned in powerful and flexible ways.

Hierarchical security groups the Archibus tasks and fields into roles and groups. Implementing security becomes a matter of deciding how roles at your site differ from the standard.

For instance, do your CIOs also want to see all of the review-level detail? If so, add the %rev% group to their role along with the %cio group.

Two key goals of hierarchical security are:

Roles and Groups

Hierarchical security for group codes covers most of the distance to achieving these goals, with roles and VPAs giving sites the flexibility to further combine and map these security groups according to their own needs.

Roles

Roles correspond to the types of users (and therefore the types of access each user needs).

Each role is like a key ring giving access to a select set of areas of the application. Roles can include parameters controlling menu access, row access (VPA), and column access (security groups and hierarchical security groups).

Groups

If a role is like a key ring, the individual groups are the keys.

These keys can grant access to processes on the Navigator, and edit and review rights on individual fields.

You assign groups to roles to assemble the selection of keys or rights that that role should have. You can also assign groups to individual users, but you should favor assigning them to roles, since this method reduces the amount of security administration you need.

You can use regular groups (which must match exactly) or hierarchical groups. Hierarchical groups act like a hierarchy of master keys, with each master being able to open an entire set of related doors. Just as with physical keys, using these "master keys" or hierarchical groups can greatly reduce the number of groups you need to define, maintain, and assign.

Users

At sites using security, users are those allowed to log in to the system. When they log in, users are granted the rights associated with their role. They may have other per-user settings, such as a VPA restriction.

Processes

Each user may be assigned one or more processes (e.g. the Craftsperson or the Supervisor process). These determine what role-specific tasks appear on your Navigator menu when you sign in.

Hierarchical Security Groups

When you use hierarchical security groups, security is simplified in that you:

Groups and their Useful Combinations

Hierarchical security lets you combine and manipulate security groups according to a structured plan.

Groups

Groups define the "atomic" or lowest level of access that users need to complete a certain process within the Archibus applications. For instance, you might divide responsibilities for:

Combining Groups with Substrings

Within an integrated, organization-wide database, however, you will have different divisions or departments responsible for different functions. For instance, you might have a "spac" group responsible for Space management and a "bops" group responsible for Building Operations.

That is to say, the set of groups you need are the cross-product of the business function and the role, such as:

While this is a great organization from an abstract standpoint, there is a practical problem in that you now have a very large number of groups. You have also broken out the schema elements so finely that you need to have a wildcard feature to assign, for instance, all space elements at once (by assigning a user group of ‘spac%’ to the user and with this assignment giving them access to all schema groups that begin with "spac").

Hierarchical security provides these wildcards. If hierarchical security is enabled and if the user group contains a percent sign (%) as a wildcard, the program uses the "substring rule" for comparing schema groups to user groups.

Combining Groups with Hierarchies or Prefixes

Also, even within a department, certain roles subsume other roles. An edit user for a certain set of data has rights to review that data as well. A manager has rights to edit the data. You need to be able to nest review permissions within edit groups, and edit permissions within managerial groups.

That is to say:

You can say that the security needs follow a hierarchy of access. If you design the set of group codes according to a planned structure, lower levels of the hierarchy are prefixes of the groups that grant higher levels of access. To add rights, just tack on another "rev" or "ed" or "mgr" suffix in the right order. Each suffix acts as an "access key" granting access to another, broader level of schema elements.

More particularly, if the schema group (e.g. "spac-rev") assigned to an element is a prefix of the user group (e.g. "spac-rev-edit’) the user will have access to that schema element.

Therefore, if you enable hierarchical security and if the user group does not contain a percent sign (%) as a wildcard, then the program uses the "prefix rule" for comparing schema groups to user groups.

The Substring and Prefix Rules

The substring rule above differs from the prefix rule in that:

The example below illustrates the difference.

For the substring rule:

A schema group of ‘space-rev-ed’ or ‘spac-rev-mgr’ matches a user group of ‘spac-rev%’

For the prefix rule:

A schema group of ‘spac-rev-ed’ or ‘spac-rev-mgr’ does not match a user group of ‘space-rev’. However, a schema group of ‘spac-rev’ matches a user group of ‘space-rev-ed’.

In other words:

For instance, using the substring rule to assign a role or user to group "%cad%" would inclusively grant rights to all schema groups LIKE "%cad%". That is to say, for all schema groups which contain the letters "cad" as a substring, such as rplm-rev-ed-cad, or spac-rev-ed-cad (since these satisfy the wildcard match).

However, using the prefix rule to assign a role or user to group rplm-rev-ed group (review and edit permissions the RPLM domain) would:

Access Keys

Access keys do not correspond to any feature; they are part of the convention for naming groups so that you can perform meaningful substring and prefix searches on groups.

The conventions are:

Archibus group codes are assembled from "access keys" in a manner analogous to the way that Archibus layers are assembled from layer prefixes (e.g. "WA’, "RM") and suffixes (e.g. "-EXT", "$TXT").

Assigning Domain-Independent or Application-Independent User Groups

The rules become clearer with some examples. One use of Substring Groups is to grant cross-domain rights to certain types of tasks and fields -- regardless of what domain or application those tasks or fields belong to.

Substring Group  
%cad% all Cad specialists tasks
%rev%  all review tasks
%rev-ed%  all review and all edit tasks
%rev-ed-calc% all review, edit, and recalc tasks
%em%  all employee tasks
%mgr% all managerial tasks
%dba%  all Database Administrator tasks
%cio% all CIO or top-level analysis results and KPIs
%sysint% all System Integrator tasks

Assigning Domain-Specific or Application-Specific User Groups

A typical example of the use of hierarchical groups is to grant nested rights to specific processes within a domain.

Substring Group Grants Access to...
rplm% Substring group granting rights to all of the rplm features
rplm-rev  Review features of rplm only
rplm-rev-ceo  Review features of rplm that show summary and KPI results
rplm-rev-ed Review and edit features of rplm
rplm-rev-ed-cad  Review, edit, and CAD features of rplms
rplm-rev-ed-calc All of the above plus results recalculation (e.g. analyze cost) features
spac%  Similar to rplm
spac-rev Similar to rplm
spac-rev-ed Similar to rplm
spac-rev-ed-calc Similar to rplm
spac-rev-ed-cad Similar to rplm
spac-ep   All features of Emergency Prep application
spac-ep-rev All review features
spac-ep-rev-em   Employee review features only (e.g. Advisory Bulletin for Employees)
spac-ep-rev-ed  All review and edit features
spac-ep-rev-ed-rt  All review, but edit features only for the Recovery Team features
spac-ep-rev-ed-rt-mgr   All review, but edit features only for the RT and Manager features (e.g. Advisory Bulletin)
spac-ep-rev-ed-cad   All review, edit, and CAD features
bops%   All features of Building Ops
bops-rev   All review features
bops-rev-ed  All review and edit features
bops-rev-ed-cf   All review and edit features appropriate for craftspersons
bops-rev-ed-cf-mgr   All review and edit features appropriate for managers
bops-rev-ed-cf-admin All review and edit features appropriate for bldg ops site administrators
sys% All system management features
sys-dba All database admin features (backups, passwords)
 sys-dba-pers   All DBA plus personalization features (hotlists, VPA restrictions)
sys-dba-pers-sysint   All of the above plus system integrator features (Archibus Fields table, Schema Change Wizard)

Example: Editing the Buildings table

The Buildings table has one of the following two Security Groups assigned to many of its fields:

Suppose the %WORKFLOW% users do not include the above two security groups; Archibus prevents users in the %WORKFLOW% roles from editing those fields.