![]() ![]()
Access
Road 0.7.1
|
|
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 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. |
![]()
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 '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:
|
![]()
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 '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:
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 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). |
![]()
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 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. |
![]()
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 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. |
![]()
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 – 02 May 2012