Introducing t he
complex ACS properties
For the advanced
users, this section explains how an ACS may have a precise
behavior through the customization of some ACS properties. This
section is not useful for understanding the other sections. We
have seen Access Road forbids the creation of an Actor under the
directory 'home' in a Linux Ubuntu ACS. No Linux rule nor Ubuntu
rule there, but an application of the best practices in the Linux
Ubuntu administration. This is an example of when Access Road
goes over the basic simulation of a software. The ACS property
which is responsible of such a behavior for Linux Ubuntu is the
generic property 'Container / Resource / ACL / Privilege type
POLICIES'. But let's now see the properties of 'rbc'.
Click in the
explorer on the node 'rbc', then in the beamer click on the tab
'Types'. In the beamer maps, the keys list is at left. The
selection of a key produces the displaying of the associated
values in the values list at right. In the left list of the
property 'A. All the ACS object TYPES...', select the key
'Resource.ResourceType'. This is how this map appears:

This first property 'All
the ACS object TYPES, and all the 'CreationByBeamer' type POLICY'
is a complex map covering several functions to configure the ACS.
Let's just say this key 'Resource.ResourceType' defines all the
possible types a resource may have in an ACS, whatever its type.
The number of usable types is very low. This is because all the
RBAC application Resources are modeled as transactions put in
some sets. All the access controls are simply about what right
user may access to what transaction.
In the left list of
the property 'A. All the ACS object TYPES...', select the key
'EligibleParty.EPType'.
The key
'EligibleParty.EPType' defines all the possible types an
EligibleParty may have in an ACS. This is the set of types to
apply at the creation of an EligibleParty. The
list at right shows a greater number of values, ended with 'role'
or 'group'. Once again, we find the functional group names.
These ACS properties cannot be changed after the creation of the
ACS. This is the responsibility of the ACS designer to allow or
not the user to switch the type of an ACS object freely after its
creation. This is done by the
second property 'Container / Resource / ACL / Privilege type
POLICIES', in the same beamer tab.
For
instance, into a Linux Ubuntu, the key
'Directory.TypeOfChildFor.directory'
defines the allowed types for the children for a standard
directory. The values list contains 'directory', 'file' and
'executable' for the children. There, for the ACS 'rbc', there is
no key 'Directory.TypeOfChildFor.directory' since 'directory' is
not a Resource type. The key
'Directory.TypeOfChildFor.transaction set' has only one value:
'transaction'. A general rule is that the value 'transaction'
authorizes also the value '<immutable> transaction', as a
child of a transaction set.
This
second property 'Container / Resource / ACL / Privilege type
POLICIES' has many other functions. Access
Road forbids in the ACS 'rbc' the adding of a GroupID as member
of another GroupID having the type 'security audit role'. This is
done through the first key of the left list, named
'GroupID.TypesOfMemberFor.security audit role', where the single
value is 'personal user account'.
Another type policy in
the first property, through the key 'CreationByBeamer.NoType',
has the responsibility to forbid some types at the creation of an
ACS object through the GUI. This key is associated to a complex
list of values, where some of them start with 'UserIDType.' to
forbid a type at the creation of an UserID. For instance, the
value 'UserIDType.administrator role' is set. By the way, most of
the EligibleParty types are forbidden, so that only a 'personal
user account' may be created as UserID.
Generally speaking,
Access Road manages a network of positive and negative
StringRights. A StringRight has a strength. It may be linked to
some upper rights and some lower rights (see the beamer tab
'Rights' on any StringRight). In some ACS, the rights are created
by pair: one positive right and one negative right.
For some ACS addons,
there is a name pattern to convert the right of a Directory to a
right on its child. This may lead to create a right the simulated
software does not know. For instance, in Linux Ubuntu ACS, the
tab 'Rules' in the beamer explains: a pitfall is that 'r', as
an inherited right from the parent, does not mean 'read', as when
it is a direct right, but it means 'goto' and 'view'. This is why
Access Road defines the right 'rdir' for a directory. Inherited
right or not, 'rdir' has these varied meanings to replace 'r'.
This tab 'Rules' explains the complex properties of an ACS to the
advanced users.
How a set of rights is
attributed by the ACS is another important function. Click on
the tab 'Rights'. The first
property 'A. Standard Rights' defines the standard rights for
each type of rights, like the Account rights of the Account/Group
rights, and the AclEntry rights. Most of the keys are for varied
Privilege rights, but the privileges are partially implemented in
the version 0.7. The first key 'Resource.AclRights' defines the
standard AclEntry rights of this ACS.

There is no value there because this first property is overridden
by the second one, called 'B. Specialized Rights', which is more
fine-grained. The first key 'Source.AclRightsSet.Type.security
audit role' defines for an access source ('Source') having the
type 'security audit role', the permissible AclEntry rights
('AclRightsSet').

The values are 'audit update' and 'connect', so that the group
'security audit', only one to have this type into this ACS, may
use only these two ACS rights on any ACS Resource.
These two images at right shows what Access Road proposes when an
AclEntry is created for the GroupID 'security audit'.
When an AclEntry is created, the set of permissible AclEntry
rights cannot be selected until the ACS is known. If the user
click on the 'Select_3' button for 'List of Rights' before the
selection of the ACL source (the Right User), the list of
proposed rights is larger. However, the base would reject any new
ACL having a wrong right for the couple (source, target). This is
why it is recommended, whatever the object to create, to simply
select the properties in the order of their presentation, like
into these images, to have the better list of values for each
property selection.
Unfortunately, there are still some complex cases where the
permissible values cannot be known by the GUI at this step,
because the constraints are the result of a complex processing in
an ACS addon. In these cases, the object creation may rejected by
the base after the selection of all the properties. In all cases
of error, a message informs the user about the issue.
The aim of this tutorial
is not to explain all these complex ACS properties. The Javadoc
documentation of Access Road is the best entry point to know how
to create a new ACS, or to modify the properties of an ACS copy.
We have simply to
remember that the ACS behavior is very flexible with these
properties. The user is always guided step-by-step to fulfill
with the requirements of each ACS. Here is a last example. To be
easier to use, the beamer does not display some tabs or some
properties when they are not applicable. In the ACS 'rbc', the
directory 'finance' has no 'ACL' tab because it is not authorized
by the ACS policy, nor the tabs 'AG' or 'AG inheritance'. All
these features make Access Road is a framework for varied
simulators.
|