Access Road 0.7
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 on the 'OK' button.

A dialog selection appears about the parent. Click on 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 on '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 on the type 'physical' to have a physical component for the new Linux, then click on '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 on the 'OK' button.

A dialog selection appears about the parent. Click on 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 on '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 on 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 the 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.





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 on 'OK'. The third dialog appears to select the initial objects of the new view. In the explorer, click on the Resource 'shareholders', then on the GroupIDs 'finance' and its 3 'finance' members, then click on 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 on 'OK'.

We remark that 'finance manager' is both a member of the groups 'extended management' and 'finance', so that 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 the image above, 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'. Remember that 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'.

In the explorer, the 'Types of ACS rights' of the ACS 'rbc' is quite simple. Clicking on 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. The view may be so summarized by: 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 ACS, the logic is so simple it is not really useful to read the 'See why' text.

This is a typical pattern in a role-based access control model. These groups are called functional because they match the true organization of the tasks and the responsibilities in the company.

This is a second view about the rights of the UserID 'Aïcha'. This is 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.


If Aïcha needs to consult, for three weeks, some specific data through the 'shareholders' transaction, it is easy to add her to the group 'finance transient', just at its right into this diagram.

With its structure of roles, the design of access control in the RBAC application fulfills with some balanced requirements we will not study in this tutorial, but which 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 'shar' in the two fields, then click on 'OK'. The third dialog appears to select the initial right users (not the single access target) of the new view. In the explorer, click on 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 on 'OK'.

The NoMore-NoLess view 'shar 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 on the 'Select' button of the property 'Access Target'. Select the resource 'shareholders'. Click on 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 on 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 on 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 path, but only the first reason to tell a rule is not complied with. It is not a surprise to read that 'finance manager' is this reason there. Of course, the full views and the NoMore-NoLess views provide always consistent results.

In the beamer showing the NoMore-NoLess view, click on 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 on 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 most 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 even 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 easy to have a set of NoMore-NoLess views to ensure the access control policy is fulfilled. To analyze more precisely an issue, it is always possible to create a full view similar to a NoMore-NoLess view. Remember the general 'NoMore-NoLess Views' window may displays 10 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 a 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 'd_enter' means the 'enter data' right is denied.

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 is a good tool to assert the fulfillment of requirements on availability.

Follow the procedure to create a NoMore-NoLess view named 'rbc:: loads', containing the group 'accounts manager' and the access target 'loads'. Select the No-Less-Than right 'connect'. Here is the result. 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.

Note: Access Road is able to subtract negative rights from some positive rights, for the need of a simulation. However, this needs to be done in an ACS addon. In such a case, the 'See why' text displays for a link, all the positive rights, all the negative rights, then the result of the subtraction in the ending field 'All Rights'.





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 on the node of this view. In the menu, select the command File -> Export image. Select 'Yes' to confirm the export, and click on 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. 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, AclEntries and linked Privileges. It rather returns a map containing the description of these closed objects. The user may choose to create some of these closed objects. The returned map described each Bridge, AclEntry or Privilege, including the names of the rights. This part of the procedure is not visible in our simple case.

After the operation, the imported ACS is open. A saving updates the initial file of the imported ACS.


Comparing two access control states

The best way to compare two states or two version of a design is to work in parallel on two instances of Access Road. This is very simple, since each instance knows only its own working directory.

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 anormal 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 basic tutorials is to give you the knowledge to use Access Road. Along more than four hours of hard work, after 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


Creating RBAC | ACS properties | Discovering RBAC
Creating NoMore-NoLess view | Negative rights | Export and import
Comparing two access control states

®All trademarks are property of their respective holders. Copyright ACCBEE – 22 February 2012