![]() ![]()
Access
Road 0.7.3
|
|
Creating
RBAC |
ACS
properties |
Discovering
RBAC
This third tutorial explains several independent matters, like how to verify the access control set-ups of a simulated software, and, from the release 0.7.3, how to handle the user identity and the IP addresses. 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 is recommended to all the users. However, it is not mandatory to read it to perform Access Road, and it is also possible to skip some sections. The second tutorial is a requisite, but it is not necessary to know the RBAC model. This third tutorial introduces the following features:
The best way is to use twice each chapter of this tutorial: first as a simple reading, and then to operate on Access Road. The total duration is estimated at 3 hours. When a chapter is optional, it is independent of the other ones and this is recalled at its start. How to exit Access Road and save the current configuration is shown at the end of this first 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 other ACS may be closed because they are children of the selected one. Some messages may appear to indicate that the open views are closing, since they are associated to a closing ACS. Confirm all these messages. Close the Sketcher if it is opened (click the window cross). We follow the procedure to create an ACS, from 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 create a physical component for the new Ubuntu, then click 'OK'. A last dialog proposes to create another component. Click 'No' then 'OK'. The Linux Ubuntu ACS 'hu' is created, saved, opened and selected in the explorer. To create the out-of-the-box simulation of a RBAC application as a GNU/Linux Ubuntu 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 to select the direct parent. Click the node 'IO:: three:: hu' then 'OK', to set 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'. A dialog 'Select the parent ACS' appears. Select the single choice (the ACS 'hu') then click 'OK'. Confirm the 3 messages about the creation of the ACS components. The RBAC application ACS 'rbc' is created, saved, 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. The explorer shows for the RBAC application 'rbc' the common nodes we know for an ACS. In the beamer, the ACS tab 'Structure' shows the 24 booleans defining the main structural properties of an ACS. This is a simple ACS structure, where the main properties are 'internal/external AclEntries' and 'nested accounts groups'. This latter boolean is new, since not 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 nested account groups. The functional tree of groups is the ground of the role-based access controls. Under the node '<functional_tree>', there is a 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 tool 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: ![]() ![]()
To see in one look the logic of an ACS, the best way 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, 'finance manager' below it, and 'extended management' at right of the diagram (right-click the image to see it better). 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. 'finance transient' has an indirect path to 'shareholders' through 'finance'. 'finance' has NOT an indirect path through 'finance operational' on 'shareholders'. From 'finance' to 'finance operational' and 'finance manager', the right on 'shareholders' increases, from 'browse' to 'enter' and 'control'. To see what right is greater, click the explorer node 'ACS rights' for the RBAC ACS, and click the right 'browse data'. In the beamer, click the tab 'ACL' to read the upper rights: 'enter data' is greater than 'browse data'. A click on the 'Upper rights' See button produces a jump to the right 'enter data' and its tab 'ACL', where it appears that 'control' is its upper right. The basic right 'browse data' 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' . The actor 'shareholders' may receive a Group context from most of the groups in this view. This is the meaning of the 4 'recv contxt' arrows from the node 'shareholders'. 'recv contxt' stands for 'received context'. It is the inverse relation of 'init contxt', seen in the previous tutorial. This view may 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 demonstrates a typical pattern in a role-based access control model. The 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. Here 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 view 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 same strategy 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', visible at its right in the diagram, and to unregister her after 3 weeks. Then, Aîcha may browse the 'shareholders' data through a very simple administration action. Such a diagram is very useful to remind the logic of the access controls. This is an unique feature of Access Road. Note: this view cannot be get by your Access Road program. It has modeled 'shareholders' and 'loads' as simple Resources, and not Actors, to have a simpler presentation without any 'recv contxt' link. Using a strong structure of roles modeled as groups, the design of access control in the RBAC application fulfills with some balanced requirements. We will not study them in details. The limited examples presented above are sufficient to catch the essence of the RBAC model. The requirements are summarized hereafter:
|
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
Adding an user comment to a full view
A full view supports short user-defined comments since Access Road 0.7.3. Select the opened full view, and into the beamer, the 'New' button of the property 'Elements & comments'. A dialog window appears. Select 'Comment to write' then 'OK'. A dialog 'Enter a new command line, at number 1,...' appears. To limit the size of the comment, the dialog forbids a text larger than 12 characters. Enter the text 'the most' then 'return' or click 'OK'. A second dialog appears. You may close it to stop the text edition, or you may enter a second short line of text. If the text is too long, there is the error message 'This line of comment is too long. 12 characters is the maximum'. In such a case, click 'OK' to close the error window. A new dialog window will be displayed to enter a new text. The procedure is repeated for entering a third line. You may choose to enter 'powerful' as second line, and 'group' as third line. At the end, a question window appears: 'Do you confirm this view comment?' The window recalls the 3 lines of entered text: 'the most, powerful, group'. Click 'OK'. Otherwise, the procedure would restart to enter from 1 to 3 new lines of text. Closing the dialog window of the first line of text, or letting an empty field when the OK button is clicked would stop the creation of the user comment. ![]() The new comment is displayed in the beamer and into the view diagram. The upper case is not workable there. The comment is numbered at 0. The next comment would have the number 1, and so on. Since this first comment is about the 'finance manager' group, drag&drop the image of the comment at the right of this group, in the diagram. The drag&drop action handles the view element icons and the comments the same way. The user comments are saved with their current position in the diagram. There are not displayed by the 'See why' text. An user comment is deleted exactly like a view element, that is, through the property 'Elements & comments' into the beamer. Save your current work through the command File → Save All (Ctrl+s). |
|
Creating a NoMore-NoLess view
By the way of a clear diagram, the full view 'rbc:: share' shows the general logic of the rights. When the IT system is complex, implying varied personal and skills, a good practice is to write a security policy for the access controls. 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 one access target. It allows to set a maximum right, the NoMore right, and/or a minimum right, the NoLess right. A NoMore-NoLess view contains exactly one access target. This kind of view checks if, among the set of right users the view contains, there is one right user which has a right greater than the NoMore right. The same principle, in the inverse sens, is applied for the NoLess right as a criterion of compliance. To control the previous policy about the transaction 'shareholders', a NoMore-NoLess view may contain 'shareholders' as single target, and several right users to check if a 'total control' is get on this transaction. 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 Account and Finance 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 as criterion. 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 user-selected 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 it. This includes also, for a GroupID, all its direct and indirect members. This extended 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 which 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 than a full view text. The main result is: NO COMPLIANCE FROM THE RIGHT USER IO:: three:: hu:: rbc:: <G>:: finance manager:: Link number 1: Global 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 describes only the first reason to tell a NoMore or NoLess criterion is not fulfilled with. It is not a surprise to read that 'finance manager' is the first reason there. We may compare the open full view and the new NoMore-NoLess view. The text 'fulctr' in the full view diagram is the standard acronym about the metaright 'full_control' (called 'generic right' in the explorer and the beamer). This metaright is always displayed with this acronym into all the diagrams, whatever the ACS. On the other hand, the 'See why' text of a full view or a NoMore-NoLess view displays the ACS right, 'control' there, that has 'full_control' as metaright. We can see the two kinds of view provide the same 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'. To do it, you may click directly the representation of this object in any view diagram. The NoMore-NoLess view is updated, turning to Green the 'enter data' right. To tell 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'. Whatever the evolution of the properties in the Access Road base, a NoMore-NoLess view, once created and saved, provides a continuous control about an access control policy. Close the related view to stop the control. A NoMore-NoLess view cannot contain more than 9 user-selected right users. The number of excluded right users is also limited to 9. The checking perimeter can contain up to 50 objects. If an user-selected excluded right user is not into the checking perimeter, then it is ignored. On the contrary of a full view, it is not possible to change the position of a node by drag&drop. However, a NoMore-NoLess view has plenty of common characteristics with a full view:
The NoLess criterion works in the NoMore-NoLess view just like the more criterion, but with an inversion of the control. The NoLess 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 at the next chapter about the negative rights. The NoLess criterion and the NoMore criterion are strictly independent. The two criteria may be identical in the same view, to control the use of one precise right. A
NoMore-NoLess view is a simple tool to check the rights During the maintenance of an access control design, a set of NoMore-NoLess views may be very useful. It is easy to verify if the access control policy is fulfilled. For analyzing an issue, it is always possible to create a full view similar to a NoMore-NoLess view. The general 'NoMore-NoLess Views' window may displays 20 views and more (through the menu command: Window → All NoMore-NoLess Views). |
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
Introducing the negative rights
This chapter is optional and independent of the other ones. At the moment, the tutorials have handled only positive rights. This optional 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 security officer of this company may think it is prudent to limit the rights of the personal working 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'. The view 'rbc:: loads' is updated, and the result is at right. The acronym 'launc' means the right to 'launch' the process 'loads'. This is indeed the result of a subtraction of rights: [control - deny_enter_data = launch]. The lower rights of 'control' are 'deny_enter_data' and 'launch'. In such a case, Access Road subtracts the rights to get the effective one(s). The first path in the 'See Why' text produces a negative right. 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 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'. This criterion is displayed in red, because it is not fulfilled with for 'John', member of the 'accounts manager' group. This NoLess criterion assets that the right 'enter_data' is no more available on the transaction 'loads'. A requirement on availability is checked with a NoLess criterion from the point of view of the modeled software. In this example, we see if the RBAC application is correctly configured, but this is not a guarantee about the availability. For instance, if the access controls define a path through a right-proxy actor as intermediate node, the current model does not know if this actor provides an effective access through this path. ![]() Whatever the nodes in a full view, the overall result is exactly the same, even with some negative rights. The second tutorial, at the end of the section 'The updating of an Access Road full view', shows a first-rate link with its double-length-line arrow in the diagram of the view 'sqyl:: jerry:: '. A first-rate link forbids all the indirect paths between two nodes. In the case of the view 'rbc:: loads:: ', what if the group 'accounts manager', which contains the account 'John', is added to the view? Add 'accounts manager' to the view. The result is get there. The 'See why' text displays: FROM IO:: three:: hu:: rbc:: <U>:: John TO IO:: three:: hu:: rbc:: <rbc operations>:: accountancy:: loads. RIGHTS: [deny_enter data] PATH NUMBER 1: Link number 1: Negative ACL: d_enter; -- Global <negative rights from other paths> <Caution: to subtract to indirect paths> -- All Rights: deny_enter data Without 'accounts manager' in the view, Access Road has performed a subtraction of rights. Now, it displays independently the negative right 'deny_enter_data' for 'John', and the positive right 'full_control' for 'accounts manager'. Reading this view, the user has to provide the subtraction of rights by its own. This is why the 'See why' text includes '<Caution: to subtract to indirect paths>'. Such a path is called a to-subtract-to access path. It is not a first-rate link, since the indirect paths are applicable. Instead of marking the arrow in the diagram, like for a first-rate link, a to-subtract-to link is displayed as a normal link. It means its rights have to be combined to the rights from the indirect paths, as usual, to deduce the overall rights between the two nodes. We have seen the main issues about the negative rights. The next section describes a last example, when a context switch produces a false reading of the indirect paths in a view. Save your current work through the command File → Save All (Ctrl+s). |
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
Managing the user identity with the context switches
This chapter is optional and independent of the other ones. It introduces some improvements of the release 0.7.3. It may be followed without reading of the previous chapters on the RBAC application, the ACS properties, the NoMore-NoLess view and the negative rights. Access Road allows to manage the user identity through the connections of several software. This new feature includes the followings:
The concept of principal is an extension of the concept of user identity. The principal has a set of accounts and groups which is the ground of its access rights. Access Road models this set as a so-called Account/Groups context of an access path. Going across a frontier between two software often changes the AG context of an access path. Some ways like (ACS A- ACS B - ACS B) are possible, so an access path may also keep in memory the AG context of its first ACS while the last node is processed. The release 0.7.3 extends the concept of transfered Account/Groups context. It manages these transfers between connected software by the way of new concepts: entry context switch and exit context switch, communication end point and data exchange point. ContextSwitch and ExchangePoint are the new kinds of Actor which implement these concepts. They ensure the handling (continuity/deletion/replacement/recovery) of the principal through the data exchanges in a network. They are also applied between the processes and the applications of an operating system. Using ContextSwitches is introduced in this section. The next one covers the ExchangePoints. The release 0.7.3 brings also the managing of the IP addresses, both in ContextSwitch, ExchangePoint and the IS structure. IP addresses are presented in the next section. For exploring the configurations of the session user identity, we need an Ubuntu server running a RBAC application and a MySQL server. Close all the open views. Following this procedure, create the MySQL Server ACS 'mys' under the ACS 'hu'. In the release 0.7.3, a MySQL server ACS has a new resource by default. It is called '<entrance_gate>', under 'connection_subacs'. This is an example of entry context switch (or entry CSW). ![]() To study '<entrance_gate>' in action, let's create a full view named '3acs:: one'. Populate this view with these 3 'mys' components: '<entrance_gate>', the UserID 'anonymous' and the table 'Products table'. Enlarge the diagram window and enlarge the window to get the following image. The 3 nodes are put at right to let the other places for some future nodes from the ACS 'rbc' and 'hu'. 1 - The first example shows how an unknown application may access only to the MySQL account 'anonymous' on the MySQL server. Look at the properties of the entry context switch '<entrance_gate>'. In the tab 'General', its default comment is: 'The MySQL Server gate for all the incoming streams directly from its GNU/Linux server'. The first step is to explore the default behavior of '<entrance_gate>', that is, how the MySQL entry context switch selects the account 'anonymous' by default. This is the selection when, like in your new view, '<entrance_gate>' receives no incoming stream. Then, as Actor, the context switch runs under this MySQL account 'anonymous'. A context switch is displayed in the beamer with a new tab 'As Switch' we will see later. ![]() Add to the view '3acs:: one' the UserID 'John' from the ACS 'rbc'. For the moment, this account has no relation with the MySQL ACS 'mys'. To get the view at right, we will create a first ACL relation: Select the node '<entrance_gate>' and its ACL tab; create a new 'rbc' ACL for the right user '<database_handler>' (in the RBAC ACS, just under the Resources tree), with the right 'launch' and no condition group. To create an ACL, see the second tutorial. This ACL is managed by the RBAC ACS, not by the MySQL ACS. The Actor '<database_handler>' is a kind of proxy, into the RBAC application, for all the RBAC transactions having to access a database. In the release 0.7.3, it is the common ACL target of these transactions. The 'See why' text of the view displays 26 indirect paths from 'John' to '<entrance_gate>', all through '<database_handler>'. There are also 6 hidden redundant paths, for the same pair of nodes. This is how the RBAC account 'John' may be logged on the MySQL server 'mys', when it uses a RBAC transaction. After the logging of 'John', the switching on a MySQL account is delivered by the entry CSW '<entrance_gate>'. If the view would contain only the nodes 'John' and 'anonymous', '<entrance_gate>' would select 'anonymous' because it does not know 'John', the calling account. But now, because '<entrance_gate>' is a view node, the normal paths starting with '<entrance_gate>' do never consider the potential callers of '<entrance_gate>' in the same view, like 'John' there. This is a general property of the full views which would produce a wrong reading by the user. The access paths implying a context switch may be confusing, but we will see how Access Road informs the user each time there is such a risk. Into the diagram , these access paths are marked by a special symbol at the center of the arrow. Fortunately, this first example is straightforward. The user is right to understand that 'John' is logged onto 'anonymous' through the work of '<entrance_gate>'. Let's remind a full view has to display the same basic data whatever its current nodes. Removing the node '<entrance_gate>' from the view, through the beamer list 'Elements & comments', would simply change the 32 paths 'John'-'<entrance_gate>' to 32 paths 'John'-'anonymous'. Adding to the view the RBAC Actor '<database_handler>' would also produce consistent results: 32 paths 'John'-'<database_handler>', one path '<database_handler>'-'<entrance_gate>', and one path '<entrance_gate>'-'anonymous'. These examples illustrate the default behavior of an entry context switch. The selection of 'anonymous' by default is there specific to the MySQL server ACS. But a context switch may do much more... 2 - The second example shows how an Ubuntu account is logged into a MySQL account, by the way of a MySQL inner function. ![]() We consider the main feature of an entry context switch: how the incoming stream is used to select a local Account/Groups context. The requisite is to have in the incoming stream a key of the entry switchings map. In a MySQL server ACS, this feature works only for the UserIDs of the Ubuntu server under which the MySQL Server runs. Remove the node 'John' from the view. Add the Ubuntu 'hu' UserID 'tom' in the view. This image shows the current state of the view. In the 'See why' text, from the Ubuntu account 'tom' to the MySQL 'Products table', the view finds a path through '<entrance_gate>' and the MySQL account 'tom'. '<entrance_gate>' switches to the MySQL account 'tom' when the path comes from the UserID 'tom', because '<entrance_gate>' has detected the Ubuntu account 'tom' in the Account/Groups context of the 2 paths tom/.../mysqd.sock/<entrance_gate>. ![]() Let's see the specific properties of a context switch like '<entrance_gate>'. The beamer tab 'As Switch' displays its entry switchings map. We see in this image the association 'parent Ubuntu tom'/'MySQL tom'. The user cannot change this map. It has been set by the AcsAddon MySQL Server. This AcsAddon updates automatically the map when a new association appears, in other words, when a parent Ubuntu UserID and a new MySQL UserID have the same name. Click the ACS 'mys' in the explorer; in the tab 'Right Users', click the 'New' button of the 'Own Eligible Parties' list. In the selection dialog, select the creation of 'UserID'. In the window dialog, enter the name 'games', select the type 'account', no administrative role and 'localhost' as first host. The MySQL account 'games' is created. Click the entry CSW '<entrance_gate>' in the explorer, and look at its entry switchings map in the beamer, at the tab 'As Switch'. During the creation of 'games', the MySQL AcsAddon has added the new key 'IO:: three:: hu:: :: games:: ' to this map, because there is an account 'games' in the Ubuntu ACS 'hu'. Note: Generally speaking, the entry switchings map may contain several values for an entry key. The values are GroupIDMembers of the same ACS. This is the first example of an access path having, as intermediate node, a node of the view! The release 0.7.3 allows that because, in this case, it would not be correct to display a path from the view node '<entrance_gate>' to the view node 'Products table'. '<entrance_gate>' is never an access source by its own for 'Products table', but only if the incoming stream has some given properties. For the 2 paths from 'tom' to 'Products table', the 'See why' text for the first link tells us, as a Global comment: 'via' path through: <connection_subacs>:: <entrance_gate>'. They are the two last components of the name for the first view node from which the access path is extended. The access path from 'tom' to 'anonymous' is another special case. This view should lead to a false perception. The user looks at some path(s) from 'tom' to '<entrance_gate>', and some path(s) from '<entrance_gate>' to 'anonymous', while 'tom' is not logged into 'anonymous'. To inform the user about this issue, a no-indirect-path path from 'tom' to 'anonymous' is automatically added by Access Road. There is no property in the database to directly explain it, since it depends on the nodes in the view. Such a path would not be added if '<entrance_gate>' would not been into the view. This new path has a negative right 'deny_access_to' ('d_acc_t' in the diagram). To explain what indirect path it is about, the 'See why' text of this path contains the Global comment: <Caution: no indirect path through> <connection_subacs>:: <entrance_gate>. A no-indirect-path path is drawn with a special symbol at the center of the arrow, where the cross suggests that it is a denying of access. The symbol is derived from the one used for the access paths with context switch. This visual association helps to remind that the no-indirect-path path is deduced from the paths with context switch. There, the path 'tom'-'Products table' is deduced from the path 'tom'-'<entrance_gate>' and the path '<entrance_gate>'-'anonymous'. Access Road is simple to use and powerful. Whatever the number and the nature of the nodes in a full view, Access Road detects such a need for a new no-indirect-path path. For instance, 'mysqld.sock' and 'mysqld' are hidden intermediate nodes into the paths from 'tom' to '<entrance_gate>'. If these nodes are added to this current view, Access Road would also detect the need to create a no-indirect-path path from 'tom' to 'anonymous'. 3 - The third example shows how an application like RBAC manages its own logging into the MySQL server. The exit context switch is the complement of the entry context switch. To explore its role, we return to the RBAC ACS and its account 'John'. Add the node 'John' to the view. Through the ACL list of '<entrance_gate>', delete the ACL we have just created, from '<database_handler>' to '<entrance_gate>'. The connection from RBAC to MySQL server is deleted. We will now create an exit context switch 'mysql_handler' into the RBAC ACS. An exit context switch completes the AG context when a path goes out of its ACS. Click the ACS 'rbc'; in the tab 'Access Targets', click the 'New' button of the 'Own Resources' list. In the selection dialog, select the creation of 'ContextSwitch'. In the window dialog, enter the name 'mysql_handler', let a null parent and select the type 'to database'. The context switch is created. Select it in the explorer, and select the tab 'As Switch' in the beamer. The entry switchings map is empty because the RBAC ACS has not filled it up. A context switch cannot be both an entry CSW and an exit CSW. After an user creation, it cannot be an entry CSW if the ACS is generic, in other words, not from an AcsAddon. Since the ACS 'rbc' is a generic one, to set 'mysql_handler' as exit CSW, the user may create a pair (key, value) into the exit switchings map. Click the button 'SeleK' for adding a new key to the property 'C. For an EXIT switch, the external AG context for a local key'. Select the RBAC account 'John'. Click the button 'Select' for adding a value. Select the MySQL account 'tom'. The following image shows the result to get in the beamer. ![]() The aim is to control the MySQL logging from the RBAC application 'rbc', when the account 'John' creates a MySQL session. We must redirect all the internal paths from '<database_handler>' to this new proxy 'mysql_handler': through the ACL tab of this exit CSW 'mysql_handler', create a new 'rbc' ACL for the right user '<database_handler>' (in the RBAC ACS, just under the Resources tree), with the right 'launch' and no condition group. The last step is to restore an ACL path from the RBAC ACS to the MySQL Server ACS, by the way of this new exit CSW: through the ACL tab of the entry CSW '<entrance_gate>', create a new 'rbc' ACL for the right user 'mysql_handler' (in the RBAC ACS, just under the Resources tree), with the right 'launch' and no condition group (caution: the ACL ACS is 'rbc', not 'mys'). ![]() Here is the new state of the view. 3 comments has been put to inform about the 3 kinds of ACS. Unlike the first use of 'John' in the view, this RBAC account has now an access to the MySQL 'Products table'. This is the work of the new exit CSW 'mysql_handler', in the RBAC application, to add the Ubuntu account 'tom' in the AG context of the path. Then, like for the Ubuntu account 'tom' in this view, the access 'John'-'Products table' depends on the entry switchings map of '<entrance_gate>' to select the MySQL account 'tom'. In this view, there is no path from 'John' to 'tom' because the switch is done for a precise access path, through 'mysql_handler' and '<entrance_gate>', not for all the paths from 'John'. The exit CSW 'mysql_handler' is able to manage the loggings of any GroupIDMember of its ACS, like 'John', for all the other ACS to connect to. It may for instance associate to the account 'John', 5 external GroupIDMembers coming from 5 different ACS, or one external GroupIDMember which is known by all the 5 ACS. On the other hand, if 2 associated GroupIDMembers are both known by the target ACS, like the MySQL server there, it is not possible for the user to constrain the choice by the target ACS. Note: the result is the same if the exit CSW 'mysql_handler' maps the account 'John' to the Ubuntu account 'tom', rather than to the MySQL account 'tom', because the two accounts 'tom' are associated in the entry switchings map of '<entrance_gate>'. Generally speaking, this means an exit CSW may add to an exit path any GroupIDMember from any open ACS. A generic ACS like RBAC may have an exit CSW, but no entry CSW. On the other hand, the switchings map of an exit CSW does not handle a default value, while 'anonymous' is the default result for the entry CSW '<entrance_gate>'. This table summarizes the 3 previous examples: ![]()
|
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
Managing the IP addresses
|
![]()
One-hour tutorial for learning access controls Two-hours tutorial for designing access controls
![]()
|
Managing the exchange points
This chapter is optional and independent of the other ones, except the previous chapter. An exchange point is an actor being both a communication end point (CEP) and a data exchange point (DEP). A data exchange point (DEP) models a socket or a pipe for a unique program named its master program. Taking the example of Ubuntu, the daemon 'mysqld' is the master program of its socket 'mysqld.sock'. In this context, sockets are bi-directional inter-process communication channels; being available in several flavors, some of them allow communication through network interfaces, others rely on the system kernel only as the carrier for local exchanges. A DEP has a strong relation to its master program, that is an Actor. The master program cannot be an ExchangePoint or a ContextSwitch. It is a 'simple' actor, like the daemon 'mysqld' for 'mysqld.sock'. When a data exchange point is created, its master program has to be defined. An Actor may be the master program of several ExchangePoints. As a communication end point, an ExchangePoint rejects the adding of its master program into its 'black' list of senders. The 'white' list of 'mysqld.sock' is now empty, and the view '3acs:: two' shows 4 paths from 'tom' to this exchange point. If the 'white' list of senders is not empty, the master program is automatically added by Access Road: Click the account 'tom' to copy its name, and paste it into the 'white' list of senders for the exchange point 'mysqld.sock'. The 'white' list is updated to contain 'tom' and 'mysqd', the master program of 'mysqld.sock'. Since the capacity groups are not there, the paths from 'tom' to 'mysqld.sock', into the view '3acs:: two', do no more include the 2 paths through these groups. Each connection between two data exchange points are specific to the ACS, if it is local, or it is handled by a network subACS (for instance as IP connections). Into an access path, the generic behavior of an ExchangePoint is to be able to participate as intermediate node each time it is a right-proxy, and even if there is no executable right on it. For a common Actor, this is false when it is not an Alias reference. On the other hand, the generic behavior of an ExchangePoint is to be an access source only to a communication end point or to its master program. This is why a data exchange point has no direct access to a simple Resource, for instance. A data exchange point defines a list of maximal rights for all the sources in the access paths including this exchange point. The default value of the maximal rights is 'full_control', which produces no constraint on the rights of the paths. The values are limited into the list to the following generic rights: 'full_control', 'read' and 'write'. The list is never empty, and 'read' is the minimal right. The criterion to compare two rights are the strengths of their generic rights. For the property 'Source maximal rights' of the context switch 'mysqld.sock', select the current value 'full_control', then click its button 'Remove'. The right 'read' replaces 'full_control' automatically. The paths from 'tom' to 'mysqld.sock', into the view '3acs:: two', is now reduced to the generic right 'read'. Click the button 'Select' and choose in the explorer the generic right 'write'. The new rights are now 'RIGHTS: [r, w, x, dlrncp]' in the 'See why' text. The Ubuntu right 'x' appears there because its associated generic right has a strength which is less than the maximal right 'write'. How the ACS manages the context switches and the exchange points is visible in the beamer tab 'Structure 2' of the ACS. Note: to get in the property 'Source maximal rights' the right 'write' alone, the way is to follow the previous procedure, then to remove the right 'read'. If the current maximal right is 'full_control', the direct adding of 'write' or 'read' would not work, because 'full_control' contains these two rights. Save your current work through the command File → Save All (Ctrl+s). |
|
Introducing the linked and typed privileges
This chapter is optional and independent of the other ones. The privileges are not managed by the current ACS, so we create a dedicated ACS for this chapter. To create the out-of-the-box simulation of an ACS for privileges, 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 'priv' for the new ACS, select the choice 'An ACS for testing VirtualFolders and Privileges', and click the 'OK' button. A dialog selection appears to select the direct parent. Click the node 'IO:: ' then 'OK'. A second question appears to create a new component. Click 'Yes' then 'OK' to create the node 'five'. ![]() The ACS 'priv' is created, saved, opened under 'five' and selected in the explorer. Click its node in the explorer, and open the sub-nodes to get this image. This ACS contains a default configuration including some Resources and UserIDs, and a set of types and linked privileges. Under the explorer node 'Privileges right user >> access target', there are the two kinds of privileges. The key word 'TYPED' is for the typed privileges, and the key word 'LINKED' for the linked privileges. A source has rights upon an access target through a typed privilege if the privilege source type is the type of the given source, and if the privilege target type is the type of the given target. For instance, the first typed privilege 'TYPED || T_one || GO || actor_1 >> resource_1', in the explorer, is named 'T_one' by its ACS, and it delivers the right 'GO' to all the sources having the type 'actor_1', for all the targets having the type 'resource_1'. A typed privilege is designed to produce rights for numerous sources on numerous targets. The user cannot change the sources and the targets of a typed privilege, since it is the responsibility of the ACS. A typed privilege is created and deleted from its ACS. The rights cannot be changed after the creation. Each time the type of an ACS object changes, the typed privileges of the ACS may take or remove a reference on this ACS object. A typed privilege does not accept a reference to an external object, in other words, from another ACS. Click the typed privilege 'TYPED || T_one || GO || actor_1 >> resource_1'. In the beamer, click the tab 'Privileges'. The main properties are 'Right user type' (or 'Source type') and 'Target type', which are immutable. Under the 'root_directory', click the node 'res_one'. In the beamer, its tab 'Privileges' appears, and the first list 'Typed privileges' contains the privilege 'T_one' as first one. This list has been updated by Access Road because 'res_one' has the type 'resource_1'. Create the full view 'priv:: one' with, as elements, the Resource 'res_one' and the UserID 'acc_one'. The 'See why' text of the view displays for the paths from 'acc_one' to 'res_one', a path given by the typed privilege 'T_two': -- PATH NUMBER 1: Link number 1: Typed PRI: GO; -- Global PRI: T_two -- All Rights: GO A linked privilege handles direct and mutable references to its sources and targets, while the rights cannot be changed after the creation of the privilege. This is the inverse behavior of an AclEntry, which has immutable references and mutable rights. A linked privilege may have a Resource or a VirtualFolder as target. For instance, the linked privilege 'LINKED || L_four || ACCESS', in the explorer, is named 'L_four' by its ACS, and its delivers the right 'ACCESS' between sources and targets which are not into its name. Add to the full view 'priv:: one' the UserID 'acc_two'. The 'See why' text of the view displays for the paths from 'acc_two' to 'res_one', a path given by the linked privilege 'L_four'. The user may update the list of right users and the list of targets of a linked privilege. However, the ACS may enforce the types of the right users and targets of a linked privilege having a given second type. This is done by the privilege types policy of the ACS. It appears through the properties 'Internal R-U Types' and 'Internal target types', in the tab 'Privileges' of the linked privilege. This is why the selection of the second type is important at the creation of a typed or linked privilege. A linked privilege is created and deleted from its ACS. Click the node of the ACS 'priv' in the explorer, and the tab 'Rights 2' in the beamer. There are 2 lists for the typed and linked privileges of this ACS, including the buttons 'New' and 'Delete'. A linked privilege accepts a reference to an external right user or an external target, if it is the ACS policy. Click the tab 'Structure 3' to see how the privileges are managed by this ACS. The property 'External One-to-one LPRI' is 'TRUE' to set the external privileges. In the explorer, the name of a linked privilege is different if it is external, including the name of its ACS at the start. The name in the explorer is so changed when the linked privilege becomes external-oriented. The privilege types policy of the ACS is also applicable to an external reference. It is visible at the beamer tab 'Types' of the ACS. A linked privilege may inherited from the Resource or VirtualFolder parent, while a typed privilege cannot. A linked privilege has no conditional groups, unlike an AclEntry. This is why the MySQL Server is modeled with AclEntries rather than linked privileges. On the other hand, an AclEntry is deleted when its Resource is deleted. A typed or linked privilege may still exist even if its sources or targets are all deleted. Save your current work through the command File → Save All (Ctrl+s). Close the full view 'priv:: one' . |
|
The export and import functions
This chapter is optional and independent of the other ones. 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>:: shar2::' view: into the 'NoMore-NoLess Views' window. Open this view. 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 procedure is the same with or without the window 'All NoMore-NoLess Views'. Close the view 'rbc:: <NMNL>:: shar2::'. The explorer, the IS structure and the beamer may also be exported as PNG images, 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 the active 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 active. 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 forbid 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, we have first to close and to remove the ACS 'sqyl'. If the ACS 'sqyl' is opened, select in the explorer the node 'sqyl'. In the main menu, use the commands File -> Close. In the main menu, use the command File -> Remove. Answer 'yes' to the question 'Remove an ACS?'. Select in the list the ACS 'sqyl'. Click 'OK' to valid the 2 information messages. Confirm the removing of the ACS 'sqyl'. The ACS 'sqyl' disappears from the IS structure. Note: after the removing of an ACS, to return to a state exactly like this Access Road instance had never known this ACS, it is necessary to close and open the parent ACS if it is opened. The child ACS in the ACS 'tubun' are checked when it is opened, and the removed child ACS are detected to delete their roots into 'tubun'. For importing an ACS, here is the procedure:
This is the first ending message after the 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 tries also to create the Bridges, the external AclEntries and external linked Privileges which connect the imported ACS to the other ACS. It cannot succeed if an ACS is closed, for instance. In all cases, the import function returns a map containing the description of the Bridges, the external AclEntries and external linked Privileges. This is the result we should get: ![]() The user may choose to create some of them, if Access Road has not been able to do the work. The returned map describes each Bridge, external AclEntry or external Privilege. For these two last objects, this includes the names of the rights. It is recommended to copy the information of this window. It is not possible to get it after the closing of the window. In your example, the information window describes a Bridge which has been created by the program, from 'mysql.sock' to '<entrance_gate>'. There is no complementary work for the user. After the operation, the imported ACS is opened. An automatic saving updates the initial file of the imported ACS. Close the ACS 'tubun'. |
|
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. Here is a tip about the savings: an ACS saving has to delete then restore any external-oriented ACS object, like an external AclEntry or a Linked Privilege which has a reference on another ACS. After the ACS restoring, the external object seems to be the same in the GUI, but it is indeed a copy of the previous one. If the beamer displays such an external object during the save/restore process, the beamer displays an empty panel after the operation. The new copy of the external object appears in the explorer, with the same properties, and the user may click it to restore it in the beamer. A last tip is about the number of windows, like the explorer window or a view diagram window, 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 may then be opened 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 to return to a normal state. Exit Access Road ![]() The final state of the IS structure is the following. A copy of the Access Road base at the end of this third tutorial may be get from the file 'accessroad073-base-after-tutorials.zip'. The purpose of the 3 tutorials is to give you the basic knowledge to use Access Road, and to transmit the 'spirit' of its simulation approach. There is a first insight on the advanced features. With the examples of Linux Ubuntu®, MySQL Server® and the RBAC application, we hope sincerely these objectives are achieved. As a framework for access control simulators, Access Road is complex in the details of its work, while its tutorials have to remain quite simple. Nonetheless, we have tried to avoid a caricature in the tutorials that distorts or forgets important things. Remember also that this version 0.7.3 is a work in progress. There are in the Access Road model several properties which are still to be fully implemented. To exit Access Road and to save the current configuration, let's see 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
Adding
an user comment |
Creating
NoMore-NoLess view |
Negative
rights
User identity and context switch |
IP addresses and 'black'/'white' senders lists
Exchange point |
Typed and linked privileges |
Export
and import
Comparing
two access control states
®All trademarks are property of their respective holders. Copyright ACCBEE – 25 May 2013