![]() ![]()
Access
Road 0.7
|
|
Creating
RBAC | ACS
properties | Discovering
RBAC
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:
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. |
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
Introducing t
|
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
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:
|
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
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:
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 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). |
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
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'. |
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
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. |
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
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