Access
Road 0.7.1 Verifying access controls
|
|
Creating
RBAC | ACS
properties | Discovering
RBAC Creating
NoMore-NoLess view | Negative
rights | Export
and import Comparing
two access control states
This
getting-started one-hour tutorial is for verifying the access
controls of a simulated software. It takes the example of a
Role-Based-Access-Control application. The RBAC model of access
control is well-known in security. It is used to simulate a
theoretical application into Access Road.
This third tutorial should be ridden by all the Access Road
users. The second tutorial about designing access controls is a
requisite. It is not necessary to know the RBAC model. The best
way, which is not a waste of time, is to read it twice: first as
a simple reading, and then to operate on Access Road. The
approach is to discover together the Access Road generic features
and a given simulation. This tutorial explains the following
actions:
creating a RBAC application
as a new ACS,
introducing some complex
properties of an ACS,
using a full view to
analyze the main characteristics of this ACS access controls,
creating a NoMore-NoLess
view to check the compliance of rights with some criteria, to
understand the access control strategy in the RBAC application,
comparing the use of the
full views and the NoMore-NoLess views,
introducing the negative
rights, through the example of AclEntries,
using the export and import
functions,
comparing two access
control states.
At any time, you may
choose to stop the tutorial before its end. How to exit Access
Road and save the current configuration is explained at the end
of this tutorial.
Creating a RBAC application ACS
Run the Access Road
program from the installation instructions. Close the central
information box. Close all the open ACS, by selecting each ACS
node then through the command File → Close. Select 'Yes, with
saving' to the message requests. Some
messages may appear to indicate some full views are closing,
since they are associated to a closing ACS. Confirm all
these messages.
We
will follow the procedure of creating an ACS, seen in the first
tutorial. The new application runs on a specific Linux server we
create first. To create the out-of-the-box simulation of a Linux
Ubuntu, select in the main menu the command File →
New → 'New Access Control system'. A
window appears. Enter the name 'IO'
for the ACS IS, the name 'hu' for the new
ACS, select the choice 'Linux Ubuntu 8.04', and click the 'OK'
button.
A
dialog selection appears about the parent. Click the
node 'IO:: ' then 'OK', to
create the new ACS (indirectly) under the IS root. A second
question appears to create a new component. Click
'Yes' then 'OK'. A dialog
named 'NEW COMPONENT under IO::' appears to create a new child of
the root. Enter the name 'three' and click the type
'physical' to have a physical component for the new Linux, then
click 'OK'.
The Linux Ubuntu ACS 'hu' is created, opened and selected in the
explorer.
To create the out-of-the-box simulation of a RBAC application as
a Linux application, select in the main menu the command File
→ New → 'New Access Control system'. A window appears.
Enter the name 'IO' for the ACS IS, the
name 'rbc' for the new ACS, select the
choice 'RBAC application', and click the 'OK' button.
A dialog selection
appears about the parent. Click the node 'IO:: three:: hu'
then 'OK', to create the new RBAC application under the node
of the Linux Ubuntu 'hu'. A second question appears to create a
new component. Click 'No' then 'OK'.
Confirm all the
messages about the creation of the ACS components. The RBAC
application ACS 'rbc' is created, opened and selected in the
explorer.
You should have the
opening of at least two internal windows: the explorer at the top
left, and the beamer at the top right. If the beamer is closed,
select in the main menu the command Window → Beamer. If
other windows are open, close them by clicking the
top right cross of their windows.
The explorer shows for 'rbc' the common nodes we know for an ACS.
In the beamer, the ACS tab 'Structure'
shows the 22 booleans which define the main structural properties
of an ACS into Access Road. This is a simple ACS
structure, where the main properties are 'internal AclEntries'
and 'accounts group trees'. This latter is new for us, since not
the Linux Ubuntu ACS nor MySQL Server ACS manage it.
In the explorer, under the 'GroupIDs (right user)' node, there
are two subACS called 'functional_tree' and 'physical_tree', as
examples of 'accounts group trees'. The functional tree is the
ground of the role-based access controls. Under the node
'<functions>', there is a structure tree of more than 20
functional groups.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
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 the
explorer on the node 'rbc', then in the beamer click 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
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 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 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 be rejected
by the base, after the selection of all the properties. In all
cases of error, a clear 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.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Discovering the RBAC application

Access Road offers
powerful tools to analyze an unknown ACS. By contrast with the
two first examples of ACS in the previous tutorials, the RBAC
application is build up strictly with the support of the generic
functions of Access Road. The explorer is the first one to use
for understanding the main components of an ACS. The ACS 'rbc'
has two main sets, the Resources tree and the GroupIDs tree, as
shown in the explorer:
The best way to see in
one look the logic of an ACS is to create a full view with
well-chosen objects. As we see that 'shareholders' is the first
financial transaction, it may appears a good idea to put it in a
full view with all the finance groups.
In the main menu,
select the command: File
→ New → 'New view'. The first dialog appears. Select
'Full view' then 'OK'. The second dialog appears to define
the full view name. Enter the names 'rbc' and 'shar' in the
two fields, then click 'OK'. The third dialog appears to
select the initial objects of the new view. In the explorer,
click the Resource 'shareholders', then on the GroupIDs
'finance' and its 3 'finance' members, then click the GroupID
'extended management' just above 'finance'. If you make an
error, the 'Remove in list(s)' button should be used to deselect
an object. When the view objects list is complete, click
'OK'.
The group 'finance manager' is
a member of both the groups 'extended management' and 'finance'.
This is why it is displayed twice in the explorer. The full view
'shar in the set rbc' appears as a diagram in the right bottom
coin of the main window. With the mouse, increase
the size of the view window. Drag&drop the objects in the view
to get this image, with 'shareholders' at the top and
'finance manager' below it.
This diagram shows that
'finance' has 3 members in this view, and some of them have
complementary rights on 'shareholders'. The sens of
a 'member of' link is given by the position of this text, near
the source of the link. This means 'finance' has NOT an indirect
path through 'finance operational' on the resource
'shareholders'. From 'finance' to 'finance operational' and
'finance manager', the right on 'shareholders' increases,
from 'browse' to 'enter' and 'control'. The basic right 'browse'
is also delivered to the transient accounts in the group 'finance
transient', member of 'finance'. The group 'extended management'
has a special role, since it has a medium-level right 'enter'
for all the managers, like there the members of the group
'finance manager' (right-click the image to enlarge it).
Let's use the GUI
to check the description of the rights. In the explorer, the
'Types of ACS rights' of the ACS 'rbc' is quite simple. Clicking
the right 'control', it appears in the beamer tab 'Rights'
that its lower right is 'enter data'. 'enter data' is the start
of a chain of rights with 'browse data' and 'connect', at the
lower levels. From the actor 'shareholders', the arrows show
that it receives the AG context from most of the groups in
this view. This is the meaning of the 4 'recv contxt' arrows
from the node 'shareholders'.
The view may then
be summarized like this: to operate on the transaction
'shareholders', there is a hierarchy of groups.
'finance manager' has the most powerful right,
then there are 'finance operational' and 'extended management'.
At the lower level, 'finance transient' can only browse data.
For this view, the logic is so simple it is not really useful
to read the 'See why' text.
This view shows
a typical pattern in a role-based access control model.
These groups are called functional because they match
an organization of tasks and responsibilities
in the company, to a range of rights on the varied resources.
This is a second view
about the rights of the UserID 'Aïcha', as the personal account
of a person which is an account manager. This second view below
has not to be created by you. It shows us that the logic of
rights is the same for the two transactions 'shareholders' and
'loads'. The logic is applied to two separate sets of groups, for
the accounts domain and the finance domain.

Let's say Aïcha, in the bottom of the view, needs to consult for three weeks,
some specific data through the 'shareholders' transaction.
It is easy to register her into the group 'finance transient',
just at its right into this diagram. Note: this view has modeled
'shareholders' and 'loads' as simple Resources, and not Actors,
to get a simpler presentation without any 'recv contxt' link.
With
its structure of roles, the
design of access control in the RBAC application fulfills with
some balanced requirements. We
will not study them in details. They are summarized
hereafter:
Simple creation of a new
application user by its adding in one physical role and one
functional role,
Simple choice of the
correct functional role for the user, since the functional roles
are the image of the organizational structure or the company,
Simple creation of
complementary interdictions from the physical locations of
users.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Creating a NoMore-NoLess view
By the way of a clear
diagram, the full view 'rbc:: aicha' shows a general logic for
the implemented rights. When the IT system is complex, implying
varied personal and skills, a best practice is to write a
security policy for the access controls. Such a policy contains
some rules like this one: Only a finance manager has a total
control on the operations of the transaction 'shareholders'.
The aim of a
NoMore-NoLess view is to control the compliance with some policy
rules about a maximum right and a minimum right. A NoMore-NoLess
view contains only one access target. More precisely, this type
of view checks if, in the set of right users the view contains,
there is one right user which has one right greater than a given
NoMore right criterion. The same principle is applied for a
NoLess right criterion.
In
the main menu, select the command:
File → New → 'New view'. The first dialog
appears. Select 'NoMore-NoLess view' then 'OK'. The second
dialog appears to define the view name. Enter the names 'rbc'
and 'shar2' in the two fields, then click 'OK'. The third
dialog appears to select the initial right users (not the single
access target) of the new view. In the explorer, click all
the GroupIDs of the second full view the last section displays,
except 'finance manager'. If you make an error, the 'Remove
in list(s)' button should be used to deselect an object. When the
view objects list is complete, click 'OK'.
The NoMore-NoLess view 'shar2 in the set <NMNL> rbc' appears
as a diagram in the right bottom coin of the main window. But
this is not a workable view, until there is an access target and
at least one right. To check the policy “Only a finance manager
has a total control on the operations of the transaction
'shareholders'”, we choose to select the right just under
'control', that is 'enter data'.
In
the beamer, where the view is visible, click the
'Select' button of the property 'Access Target'. Select the
resource 'shareholders'. Click the 'Select' button of the
property No-More-Than right'. Select the right 'enter data'. Use
the mouse to enlarge the new diagram.
The NoMore-NoLess view should appears with its selected 8
GroupIDs, and a 'enter data' right in red.
To
provide an efficient checking on the policy compliance, a
NoMore-NoLess view considers not only the rights of its own right
users, but also all the right users that are associated to.
This means, for an UserID or a GroupID right user, all the Actors
which run under this. This means
also, for a GroupID, all its direct and indirect members.
This
set of right users may be large for a view. It defines the
property 'Checking Perimeter'. In the beamer, click
the tab 'Context'. The
property 'Checking Perimeter' displays a list of right users.
This includes all the right users of the view, and also,
additional objects like 'Aicha' and 'finance manager'.
Click the 'See why' button of the view. It
is much simpler then a full view text. The main result is:
NO COMPLIANCE FROM THE RIGHT USER IO:: three:: hu:: rbc:: <G>::
finance manager::
Link number 1: no compliance with the No-More-Than criterion and
it is due to the right 'control'
The 'See why' text of a NoMore-NoLess view does not describe all
the access paths, but only the first reason to tell a rule is not
complied with. It is not a surprise to read that 'finance
manager' is the first reason there. The full views and the
NoMore-NoLess views provide always consistent results.
In the beamer showing
the NoMore-NoLess view, click the tab 'General'. There
is an empty property list called 'Excluded R. Users'. This
property allows to declare that some right users are explicitly
excluded from the view checking. Click the 'Select'
button, then select the GroupID 'finance manager'.
The view is updated, turning to Green the 'enter data' right! To
indicate where are the excluded right users, the forms of the
GroupID 'extended management' and 'finance' are drawn in Grey.
This recalls there are some exclusions in the policy control. The
'See why' text tells simply 'In this view, all the non-null right
criteria are fulfilled'.
A NoMore-NoLess view cannot contain more than 9 right users. The
number of excluded right users is also limited to 9. The checking
perimeter cannot contain more than 50 objects. If an excluded
right user is not into the checking perimeter, it is ignored.
On the contrary of a full view, it is not possible to change the
position of a node by drag&drop. But a NoMore-NoLess view has
plenty of common characteristics with a full view:
it
handles a diagram and a 'See why' text;
these
two elements are updated at every property change which modifies
the view objects or the view rights;
the
diagram nodes are active on a click, to select the relevant
object in the explorer;
the
view may be displayed in a dedicated main window, or in a tab in
a general 'NoMore-NoLess Views' window;
it
is opened, copied, closed and saved in the same way.
The less criterion
works in the NoMore-NoLess view just like the more criterion, but
with an inversion of the control. The less criterion is drawn in
red when, for at least one right user of the checking perimeter,
all its rights are strictly lesser than the less criterion. An
example is given in the next section.
The less criterion and
the more criterion are strictly independent. The two criteria may
also be identical in the same view, to check the use of one
precise right.
A NoMore-NoLess
view is a powerful tool to check the rights when the security
policy is near to be fulfilled. It facilitates both the
logical induction of a policy from a given design, the
control at the end of an on-going design, and the control of a
stable design.
During the maintenance
of the access control design, it is useful to have a set of
NoMore-NoLess views. This allows to ensure the access control
policy is always fulfilled. To analyze more precisely an issue,
it is possible to create a full view similar to a NoMore-NoLess
view. Remember the general
'NoMore-NoLess Views' window may displays 20 views and more
(Window → All
NoMore-NoLess Views).
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
Introducing the negative rights
The
tutorials have handled only positive rights, for the moment. This
section explores the use of negative AclEntries in a RBAC
application. There is a property 'Denying Rights' in the tab
'Rights' of an ACS. We create two new views for the transaction
'loads'.
Follow
the procedure to create a full view named 'rbc:: loads',
containing the transaction 'loads' and the UserID 'John'. Various
access paths are find, and the main right 'control' is get
through the functional group 'accounts manager'.
The
RBAC application uses negative rights to limit the operations on
the base of the physical site from which an user works for the
company. The physical groups are now 'Cilaos' and 'Paris'. The
top-level management of this company thinks it is prudent to
limit the rights of the personal at 'Cilaos'.
Select
the transaction 'loads' and, in the beamer, create an denying ACL
with the right 'deny_enter data' for the group 'Cilaos'. Caution:
to create a negative ACL, set the property 'sens' to 'deny' into
the creation window. The view 'rbc:: loads' is updated, and the
result is hereafter. The acronym 'launc' means the 'launch'
right. This is the result of a subtraction of rights:
control - deny_enter_data = launch. The lower rights
of 'control' are 'deny_enter_data' and 'lauch'. The 'See Why' text
shows a first path with the right 'control', and the other
paths having the right 'deny_enter_data'. In such a case, Access Road
subtracts the rights to define the effective right(s).
The seventh path in the 'See Why' text is added by Access Road
when a previous path produces a negative right. This added path
is always a direct path delivring the sum of all the negative
rights over all the paths.
An
access control policy generally defines the limitations of power
to apply to the users. A policy may also contains the
requirements on the availability of some actions for some users.
For instance, it is important that the key users, like the
administrators, keep on operating on the system. The NoLess
criterion of a NoMore-NoLess view asserts the
fulfillment of requirements on availability.
Follow
the procedure to create a NoMore-NoLess view named 'rbc:: loads2',
containing the group 'accounts manager' and the access target
'loads'. Select the No-Less-Than right 'connect'.
Here is the resulting diagram. Replace the No-Less-Than right by 'enter
data'. The No-Less-Than
criterion is displayed in red, because it is not fulfilled with
for 'John', member of the 'accounts manager' group.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|
The export and import functions
The export function
allows mainly to produce PNG images from the Access Road diagrams
and object trees. The import function allows to import in the
base an ACS created by Access Road on an another computer.
Let's see an example of
export of the 'rbc:: <NMNL>:: shar::' view: into the
'NoMore-NoLess
Views' window.
In
the explorer, click the node of this view. In the menu,
select the command File -> Export image. Select 'Yes'
to confirm the export, and click the 'OK' button.
A message confirms the
export in a PNG format, under the subdirectory 'export' of the
working directory.
The explorer, the IS
structure and the beamer may also be exported as a PNG image,
following the same procedure, except that it is necessary to
select the right object to export. For exporting the explorer
rather than a view, it is necessary to not select a view node in
the explorer, while the explorer is activated as window. For
exporting the IS structure, its window has to be activated, and a
node into this tree has to be selected. For exporting the current
image of the beamer, the beamer window has to be activated.
The operating system
native clipboard may be used to copy any text from the beamer or
a 'See why' text.
The export/import of an
ACS is a powerful feature we do not fully operate there. This tutorial
simply describes the general procedure through a removing, then
an importing of the ACS 'sqyl' into the same Access Road
instance. Each ACS is saved in the working directory of Access
Road in a dedicated file having a name like
'ACS0_IO_three_tubun_sqyl.acr' for the ACS 'sqyl'.
The imported ACS must
have the same ACS version than the current Access Road instance.
An ACS has to belong to an information system (IS), named below
'IS-name'. The imported ACS name has the String form ' IS-name::
aaaa:: bbbb:: cc:: ddddddddddd:: eeee:: ', where xxx is both a
component of the name and a component in the IS structure.
This may forbids the
importation of an ACS if there is a current ACS having the same
file name, or if there is an IS node or area in the same case. It
is not possible to change the name of the imported ACS or the
name of a current ACS.
To import an ACS, it has
to be closed before, into its source Access Road instance. It is
not necessary to remove it from this source instance, and the ACS
has not to be prepared for the export. The imported ACS file is
simply copied from its source Access Road working directory to
the working directory of the targeted Access Road instance.
For our limited example
of importing, we have first to close and to remove the ACS
'sqyl'. Select in the explorer the node 'sqyl'. In the main
menu, use the commands File -> Close, then the command File ->
Remove. The ACS 'sqyl' disappears from the IS structure. It
is exactly like this Access Road instance had never known this
ACS.
For importing an ACS,
the user has to enter the full name of the ACS, as it will appear
in the beamer, after the command File -> import ACS.
The dialog window requests to enter the ACS name. An error is
displayed if the associated file, derived from the ACS name, is
not find into the working directory. It is necessary to have one
space character at the beginning, and two space characters at the
end of the ACS name. This image shows the text the user has to
enter:

To import two ACS, one
being the child of the second one, the user has to import the
parent first. If the information system is unknown, is is added
first into the IS structure. The ACS parent name is compared to
the current nodes of the ACS IS. If the parent name does exist in
the IS, the ACS is registered under this node if there is no
child having the same name. If there is no chain of nodes in the
IS to match to the ACS parent name, a chain of nodes derived from
the ACS name, is created with only logical nodes. This is the
ending message after a correct importation:

In the imported ACS, all
the inner properties are restored, including its structure, its
behavior and its set of ACS objects. The import function never
opens the external ACSObjects of the imported ACS, and its closed
Bridges, external AclEntries and external linked Privileges.
It rather return a map containing the description of these closed
objects. The user may choose to create some of them. The returned
map describes each Bridge, external AclEntry or external Privilege,
including the names of the rights. This part of the procedure
is not covered here.
After the operation, the
imported ACS is opened. An automatic saving updates the initial
file of the imported ACS.
|
|
Comparing two access control states
From one single
installation of Access Road, an user may run two instances
without any problem if there is no creation or deletion of any
ACS or view. The user change the ACS object properties in the two
instances to compare the results in the open views. There is no
automatic saving in Access Road, so the files in the working
directory will remain unchanged with this procedure. At the end
of the comparison, the user selects the instance to save in the
working directory, and he/she closes the other one without
saving.
To work longer on the
two states of a design, the best way is to handle in parallel two
Access Road directories, after two distinct installations. Each
instance knows only its proper working directory, and the savings
are so independent. It is recommended to keep a manual log of all
the changes in the two bases, if it is necessary to merge some
parts of each design.
A last tip is about the
number of windows in the Access Road main window. This number is
limited to 20. If you try to open too numerous windows, for
instance by selecting several views to open, the GUI will stop to
open the windows after the 20th. A window main be open without
title, being empty. In this case, close the abnormal window(s),
and open the two general windows 'All full views' and 'All
NoMore-NoLess views'. This would allow you to return to a normal
state.
Exit Access Road
Save your current work through
the command File → Save All (Ctrl+s).
The purpose of the three
first tutorials is to give you the basic knowledge to use Access
Road, and a first insight on the advanced features. With the
examples of Linux Ubuntu®,
MySQL Server®
and the RBAC application, we hope sincerely this objective is
achieved.
How
to exit Access Road and save the current configuration is
described at the end of this
tutorial.
|
About
Access Road
Introduction
to Access Road
One-hour
tutorial for learning access controls
Two-hours
tutorial for designing access controls
Why
Access Road is unique
Glossary
|