Copyright
2000, 2001, 2004, 2009, 2011-2012 ACCBEE
The
Access Road documentation is free. Permission is granted to copy,
distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.1 or any later version
published by the Free Software Foundation ; with the Invariant
Section being "Introduction
to Access Road".
A copy of the license is included in the
section entitled "fdl-1.3".
A B C D E G H I L M N O P R S T U V
Access Control Link
See Link.
Access Control System (ACS) is the most important concept in Access Road. This is the simulation of a software that manages access rights in an information system (IS). An operating system, a firewall or a database management system are examples of such modeled software. A complex software may be simulated by several interconnected ACS, but generally one ACS is suffisant. An ACS is a component of an information system. It may contains the simulation of several relatively independent access control functions, like in the Linux Ubuntu®, and this defines the concept of subACS. An ACS manages mainly right users and access targets, and this is the purpose of the ACS structure. Between its components, there are varied structural and non-structural relations as AclEntry and Privilege. The varied types of right are modeled as Account/Group rights, Bridges, AclEntries or Privileges for delivering the effective StringRights to the right users into this ACS or outside this ACS.
Access Control List (or AclEntry)
The access control list manages some access rights (it is a positive ACL) or some access restrictions (it is then a negative ACL) from one eligible party to one resource. An AclEntry is conditional when it uses some condition group(s). For a given pair of (eligible party, resource), the AclEntries of an ACS are fully defined by two properties: the sens of the ACL rights (positive/ negative) and, only for a simple-condition ACL, the first condition group (See Conditional Access Control List). An ACL is created and deleted from its Resource. Its rights may be changed by the user after the creation, while its source and target are immutable. This is the inverse behavior of a Typed Privilege or a Linked Privilege. An ACL may be inherited from the Resource (in)direct parent. An ACL may be associated to several ACS. In the simplest case, the ACL, the eligible party and the ressource belong all together to the same ACS, and it is an internal ACL. Else, the ACL is external because the ACS of the source is not the ACS of the target. The most complex case is forbidden, when the ACL, its source and its target belong to three different ACS. The displayed name of an external ACL starts with the name of its ACS. An ACL contains one or more rights which follow the rights list managed by the ACS which manages this ACL. Note: if the concept of ACL is applicable, an access control may be simulated by the mean of an ACL, even if 'ACL' is not the term used in the simulated software, like in the MySQL Server which calls about 'privileges'.
An access target is an entity which has the capacity to be accessed by a right user, if the ACS allows it. A Resource is an access target in most of the cases, when the ACS policy allows it to its resource type. A groupID is always a right user, but may be an access target for its group members and for the actors which run under it. An ACS may be an access target for the other ACS.
The Account/Group (AG) rights on a Resource are the most complex ones. They include first the rights for the UserID (or account) which owns a Resource. The rights may be ACS rights and generic rights, positive and negative rights. The negative rights are subtracted from the positive rights. The ACS policy on 'OwnerRights' is an exemple of policy, and it sets the permissible account rights. The AG rights includes also the rights for the main GroupID owning the Resource. These rights are delivered to any active member of the GroupID which owns the resource. There are inherited AG rights in the core functions of Access Road, from a Directory to its Resource children. An Actor may have a current account and a current group under which it runs, and this feature may deliver AG rights to this actor. The AG rights are always internal rights for a given ACS, while it is possible to have external AclEntries or external Linked Privileges.
This is an internal property of a node into an access path. The second tutorial of Access Road explains how the 'See why' text of a full view may show an access path handling an Account/Group context. This is an extract of the tutorial : “the generic comment '<Sets Owner>' indicates there is a switch under the Account/Group context of the Actor 'function_one': 'tom' is the UserID under which 'function_one' runs as a stored function. This means that the initial current user 'jerry@localhost', with the MySQL syntax, has the rights to execute 'function_one', and this stored function runs under the UserID 'tom' which delivers to 'function_one' some ACL rights on the base 'BASE One'. In a very condensed form, this second path may be represented by the expression 'jerry/ acl/ function_one/ runs_under/ tom/ acl/ BASE One'. This is (...) a generic feature of Access Road, able for example to simulate, in a Linux Ubuntu, the behavior of a program starting under a given Account/Group context.”. The Account/Group context is also used in an access path to apply, or not, the rights of a conditional AclEntry on the Actor which is the ACL source. The AG context of a node in an access path is a set that may contain, first, an optional couple (UserID, GroupID), and, second, a list of optional GroupIDs. See also 'initial context' and 'received context'.
An ACS addon allows a developer to add easily to Access Road some Java classes for implementing new ACS functions, beyond the generic features of Access Road. Linux Ubuntu® and MySQL® are exemples of ACS addons. An ACS addon provides a dedicated guide (menu Help/ACS addon guides). The advanced user can create by hand a new ACS from the properties of an open ACS after its creation by an Addon, as it is possible to do from a generic ACS. However, the user has to make only ACS property changes that have been approved and documented by the ACS addon editor. An ACS addon is not a true plugin, because the current ACS addons are detected by Access Road at its starting, and the list of ACS addons cannot change during the program execution.
The ACS policy is a complex feature of an ACS. The simulation of a software requires to define the behavior of this software, as a complement of its structure. This definition is done in Access Road by the ACS policy, as defined at the creation of the ACS. For instance, the type of objects it is possible to create from a given ACS directory, is defined first in the structure (as 'actors are managed'), and secondly, in the ACS policy (as 'this type of directory may have actors'). In the beamer displaying an ACS, the ACS policy is shown through the properties of the tabs 'Types', 'Actions', 'Rights' and 'Rights 2'. A policy checksum allows to check the identity of the ACS policies (new in 0.7.1). The third tutorial provides an introduction to the policies. To see all the properties in an ACS policy, let's read the Javadoc documentation.
This is an access control link type, which defines the relation based on an Access Control List.
ACL rights inheritance
This is a main ACS structure property to set the AclEntries are inherited in the resources tree.
Servers and programs are typical actors in an information system, for the Access Road simulations. An actor is an acting resource which, as a kind of eligible party, may access to other resources controlled by an ACS. It may run under a given UserID and a given GroupID, and they are its initial AG context. It may also run under some secondary actor groups. It may play some special roles, as a bridge, between an another actor and some resources. Actor is the top-level entity which is both a ressource and an eligible party. As any ressource, an actor belongs to one ACS which controls it, and it may be controlled by other ACSs by the way of external AclEntries or external Linked Privileges. For these ACS, it is shown in the explorer as an external controlled actor. As any eligible party, an actor may also have access rights on ressources that are provided by other ACSs. For these last ACS, it is shown in the explorer as an external eligible actor.
AG inheritance
This is a main ACS structure property to set the Account/Group rights are inherited in the resources tree.
The beamer window displays the structure and the properties of a selected object in the explorer. Each object has a specific set of properties, and the beamer changes its display to show them each time the selected object changes in the explorer. A given ACS may specifies some small adaptations for displaying its proper objects. An ACS addon may add its proper rules and terms. The beamer is the unique window to update the Access Road objects. The only exception is for the creation and the deletion of an ACS or a view, where the operations are done through the main menu (File/New and File/Remove). The beamer always displays the current internal state of the selected object.
This is an access control link type, which defines the monodirectional relation between two Actors from different ACS, where one actor is the source having an access to the bridge target.
This is an access control link type, which defines the relation between a GroupID and one of its member.
A form of Access Control List which is workable only if the ACL eligible party (or source) is the direct or indirect member of each groupID into the ACL condition list (so-called the condition groups), or, if this ACL EP is an Actor, if its Account/Group context is a direct or indirect member of each condition group. There are two types of conditional ACL: the simple-condition ACL and the right-condition ACL. This defines two structural properties of an ACS. In a simple-condition ACL, the user sets exactly one immutable condition group when it creates the ACL. In a right-condition ACL, the condition groups are defined through the choice of the conditional rights of the ACL. For instance, the Linux Ubuntu® simulation of the authorization system uses conditional rights like 'Authorize<IF>Console', when the eligible party is a Linux UserID. This produces for the ACL a condition group 'Console', that is the name of a GroupID in the Linux Ubuntu ACS. This ACL has then enabled rights only if the ACL UserID belongs to the GroupID 'Console'. In the case of an Actor as ACL source, it is not possible to the AclEntry to 'know' what is the current Account/Group context of this Actor. This is a case where the ACL enables its rights, and the responsibility of the access path search is to use or not the rights of this ACL when the AG context of the ACL Actor source has been defined. The list of condition groups may be empty only in a right-condition ACL, and after an user updating of the conditional rights. In that case, the ACL rights are always enabled. An external ACL may be a conditional ACL, and then, the ACS of each condition group has to be the ACL source ACS or the ACL target ACS. Only the internal right-condition ACL allows several condition groups. An external ACL may be conditional. Then, it cannot have more than one condition group, and this group has to belong to the ACS of one of the two ends (it may not be the ACL ACS).
An ACS Right which is associated to one or several groupIDs of its ACS. Example: 'Authorize<IF>Console'. It is handled in a conditional AclEntry.
A directory is a resource having other resources as children, to handle a tree of resources. The relation directory/child is strong. Deleting the directory deletes the children.
It is responsible for modeling an access path, which is associated to a couple of objects in a View. This pair is the first end and the second end of the access path. The 'See Why' text is based on the displayable links of the view. A displayable link is the result Access Road provides to simulate the rights and the relations it finds into a view. The first end of the path is a right user or a privilege source, and the second end is an access target or a group member. For a couple of objects in a view, it may exist none or several displayable links. An access path may be simple, that is with only its first and second ends, or it may be indirect whether it includes some intermediate nodes. The displayable link integrates one access control link for each couple of linked nodes. The displayable link may handle an AG context for each of its nodes.
The entity for which an access control system delivers access rights or denies accesses to Resource. Actor, UserID and GroupID are kinds of eligible parties. They are all access right users. The eligible party belongs to an ACS. Another ACS may deliver access rights to an eligible party, which is then considered as an external eligible party.
<grant all to second>
This is displayed by a view when the rights owner may delegate to a second owner all the rights he gets, including his administrative rights like this one. This is implemented by the generic right '|transfer_all_rights|'.
<grant to second>
This is displayed by a view when the rights owner may delegate to a second owner all the non-administrative rights he gets, excluding his administrative rights like this one This is implemented by the generic right '|transfer_limited_rights|'.
A kind of EligibleParty that contains a set of members. GroupID and UserID are also called group members. A GroupID is sometimes presented as an 'Accounts Group' in the beamer. An ACS may manage a tree of GroupIDs, like the MySQL® ACS addon.
Hard aliasing
This is a main ACS structure property to set an ACS object may be the hard alias of another one, named the alias reference, from the same ACS. The hard alias has generally no proper rights as access source, since this is the responsibility of the alias reference. The views use the term alias of to name such a relation.
<has target right>
This is displayed by a view when the right user gets all the non-administrative rights of the target, in its proper context of execution as an Actor. This is implemented by the generic right '|get_target_rights|'.
The Information System (IS) is a tree structure to handle the varied relations between the ACS. Access Road handles an undetermined number of information systems. Each IS may be viewed as an independent space from the access point of view. An information system is created, opened, saved, closed and removed with the ACS it contains as nodes in its tree structure. It contains passive nodes, for example a physical or a logical component. An ACS may have a subACS which is managed as a separated set of components and rights, and such a subACS is a child of the ACS node in the IS tree. Among the relations from an ACS to another, there is the tied relation forcing an ACS to be open with its ACS parent. Other relations are visible in the IS window, but they are unused in the version 0.7 of Access Road.
Init contxt (initial context) or 'Run Under'
In a view, when there is an access path to an Actor where it is started from a given UserID or GroupID context, this actor runs under this UserID or a GroupID, as component of its AG context. A relation 'Run under' is created in the view from the actor to the relevant UserID or GroupID, if it is in the view. It is displayed in the view diagram as an arrow with the comment 'init contxt'. This is to be compared to the relation 'recv contxt'/'May Run Under'.
A link in a view is responsible for defining the set of link types that is applicable between near two base objects (for instance CONTAIN or ACL), including the rights between them. Access control links are used in the displayable links of a View. See also 'Link type' and 'Rights'.
There are several link types, and the main ones are presented in this glossary, like ACL, CONTAIN, OWNER, BRIDGE, or virtual member, linked privilege and is alias. Some types have negative versions when the rights are negative.
The linked privilege manages some immutable access rights (it is a positive privilege) or some access restrictions (it is then a negative privilege) from a set of eligible parties, as sources, to a set of resources or virtual folders, as targets. A linked privilege is created and deleted from its ACS. It handles 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. A linked privilege may inherited from the Resource or VirtualFolder parent. There are four types of linked privileges: simple, if-all-sources, internal one-to-one privilege and external one-to-one privilege. A linked privilege contains one or more immutable rights which follow the rights list managed by the relevant ACS which manages this privilege. If the concept of linked privilege is applicable, an access control may be simulated by Access Road by the mean of such an object, even if 'privilege' is not the term used in the software documentation. The linked privileges and the typed privileges are totally independent. Caution: the version 0.7 of Access Road fully implements the simple linked privileges into the generic access path search, but not the other kinds of linked privileges.
<may grant all to third>
This is displayed by a view when the rights owner may give to or remove from a second owner the right to give to or remove from a third owner all the delegated rights the second owner has received, including the administrative rights like this one. This is implemented by the generic right '|transfer_all_rights_to_third_party|'.
<may grant to third>
This is displayed by a view when the rights owner may give to or remove from a second owner the right to give to or remove from a third owner all the delegated non-administrative rights the second owner has received, excluding the administrative rights like this one. This is implemented by the generic right '|transfer_limited_rights_to_third_party|'.
Acronym used in a view diagram to indicate a Contain link.
<modify from root>
This is displayed by a view when the right user may perform updatings on the target state from the parent ACS, called the root, of the target ACS. This is implemented by the generic right '|modify_from_parent_acs|'.
<modify owner>
This is displayed by a view when the right user may may change the target owner in its ACS. This is implemented by the generic right '|modify_owner|'.
<modify right>
This is displayed by a view when the right user may modify all the right descriptors, but not the owner nor the super-administrator. This is implemented by the generic right '|modify_security_descriptor|'.
The name of an Access Road object always starts with its information system name, then its access control system name, followed by some other components if necessary. Two successive components in the name are separated by ':: ' in the textual representation of the name. When it is a Resource, the name contains all the hierarchical path of the resource in the resources tree. When it is an UserID (or a 'GroupID'), the first name component after the ACS name is '<U>' ('<G>' respectivelly). When it is a NoMore-NoLess view, the component before the last one in the name is '_NMNL_'.
A node is a container of leaves or others nodes in a hierarchical tree. Directory and VirtualFolder are nodes.
In a NoMore-NoLess view, the No-Less-Than right is the property to compare for stating if the less criterion is fulfilled or not. A NoMore-NoLess view may not have No-Less-Than right. In the view checking perimeter, if there is at least one right user which have all its rights lesser than the No-Less-Than right on the view access target, then the less criterion is not fulfilled in this view, and then, the No-Less-Than right is displayed in red. Otherwise, it is displayed in green.
In a NoMore-NoLess view, the No-More-Than right is the property to compare for stating if the more criterion is fulfilled or not. A NoMore-NoLess view may not have No-More-Than right. In the view checking perimeter, if there is at least one right user which have at least one right greater than the No-More-Than right on the view access target, then the more criterion is not fulfilled in this view, and then, the No-More-Than right is displayed in red. Otherwise, it is displayed in green.
OWNER link type (acronym in a view diagram: [own])
This is a structural access control link type, which defines the relation between an UserID and one of its resource.
<PROC>
This is displayed by a view to indicate a processed right. For instance, the MySQL addon sets a workable AclEntry from two to-be-mixed AclEntries, for an account and for an accounts-for-hosts group. The resulting AclEntry is not in the base but appears in the view as processed rights with the acronym '<PROC>'.
See DisplayableLink.
PRI inheritance
This is a main ACS structure property to set the linked privileges are inherited in the resources or the virtual folder tree. Among the types of linked privilege, the if-all-sources privilege is the single type which cannot be inherited. Only one target is authorized to the linked privilege if the first target is from an ACS that manages the PRI inheritance. The inherited one-to-one linked privilege may be external. The typed privileges are never implied in the privilege inheritance.
(new in 0.7.1) Access Road sets the ACS policy checksum and adds it to the ACS type. The policy checksum is immutable after the creation of the ACS. It is producted from the property values into the beamer ACS tabs 'Structure' and 'Structure 3', 'Types', 'Rights' and 'Actions'. Caution: if the ACS designer sets then unsets a policy property value, this action may modify the policy checksum, even if the state of the ACS to create is unchanged.
<read from root>
This is displayed by a view to indicate a global reading ability from the parent ACS. This is implemented by the generic right '|read_from_parent_acs|'.
An entity which is an access target in an access control system. It belongs to one access control system which controls it. Directories, Actors, Executables are kinds of resource. Following the ACS structure and policy, a resource may manage its own access control lists, may be owned by an userID, and may be member of one or several groupIDs. Through the access control lists of other ACSs, the resource may be an external controlled resource. Most of the time, an ACS manages a tree of resources.
Recv contxt (received context) or 'May Run Under'
In a view, when there is an access path to an Actor where it is executed from a given UserID or GroupID context, this actor may run under this UserID or a GroupID, as component of its AG context. A relation 'May Run under' is created in the view from the actor to the relevant UserID or GroupID, if it is in the view, and if there is at least one matched access path to the actor. It is displayed in the view diagram as an arrow with the comment 'recv contxt'. The term 'May' is used because the Actor may be accessed from other AG contexts. This is to be compared to the relation 'init contxt'/'Run Under'.
Rights
See StringRight. <read from root>
A right user is an entity which has the capacity to access to an access target, if the ACS allows it. Eligible Party is an ACS entity which is a right user, and Virtual Folder too. An ACS may be a right user by its ability to access to other ACS.
Secondary actor group
See Actor.
Sketcher in the GUI
The Sketcher window provides the simplest view in Access Road. It shows the simplest direct links and rights around a selected object in the explorer. CAUTION: only the simplest relations are shown, and if a relevant property is updated and if then, the links or the rights is changing, the Sketcher view is NOT updated.
Soft aliasing
This is a main ACS structure property to set an ACS object may be the soft alias of another one, named the alias reference, from the same ACS or not. The soft alias has generally no knowledge of its reference, while the contrary is not true. The views use the term alias of to name such a relation.
A StringRight is an ability to do an action on an ACS object. In a view diagram, each right has an acronym, at most in five letters. A positive right allows the action, and a negative right forbids it. Most of the rights are set and managed by one ACS . They are called ACS rights. The ACS rights are defined at the creation of the ACS. There are also generic rights which are not related to an ACS. Each right - ACS or generic right - is defined in a network of upper and lower rights. The upper right is a greater right, in other words, it delivers or restrains more power to the right user. The network of the generic rights defines the set of all the possible rights into all the information systems. Each ACS right has a generic right which defines its true meaning and power. Then, it becomes possible to compare the ACS rights of different ACS through the comparison of their generic rights. It is possible to add rights to summarize them in an upper right. For instance, in Linux Ubuntu®, the sum of the file rights 'r', 'w' and 'x' is the right 'full_control'. The inverse operation is to subtract a right from another right. In Linux Ubuntu, 'x' subtracted from 'full_control' gives the rights 'r' and 'w'. Then, if the ACS uses the rights subtraction, each right has an opposite right. See also Conditional Rights.
The main structural link types, as displayed in a view, are own for an UserID (OWNER), member of a GroupID (CONTAIN), indirect member of a GroupID through a chain of several CONTAIN links, alias of a hard or soft alias, and Run Under an UserID or a GroupID. A view diagram displays the structural links in blue, while the other links are in black.
The structure of an ACS is a set of 22 properties defining the main features a given ACS manages, like the handling of Account/Group rights or Virtual Folders. The structure of the ACS is displayed in the beamer into dedicated tabbed panes named 'Structure' for the 22 mandatory properties, and if it is necessary, the panes 'Structure 2', 'Structure 3' and 'Structure 4'. The 22 ACS main properties are presented in this glossary.
A subACS is an internal component of an ACS that is displayed apart in the explorer and in the information system tree. A subACS may be defined for the Resources, for the GroupIDs, or both. A subACS has generally a specific ACS policy for the types and the rights of its components. The Linux Ubuntu® ACS addon is an exemple where the subACS 'authorization' is both for Resources and GroupIDs, and the subACS 'capability' is only for GroupIDs. They are subACS because they model two distinct sub-systems into a Linux® operating system.
<superadmin>
This is displayed by a view when the right user, as super-administrator, may perform all the possible operations on the target. This is implemented by the generic right '|is_superadmin|'.
Type of an ACS object
A resource or an eligible party is created with a type, among a list of allowed values set by the ACS policy. This type is then ridden by the ACS to allow or forbid each operation on this object, and to set the range of values for each object property. For instance, the rights a resource may have in one of its ACL, may depend on both the ACL ACS, the resource type, and the eligible party type. This is the case in a RBAC application ACS (see the 'constrained specialized rights' in the tab 'rights' in the beamer). An important part of the design for a new ACS is to set the types handling in the ACS policy. Use of '<immutable>': The type may start with '<immutable>', and this means that Access Road forbids any change on the object properties. It is then usually possible for the user to change the type, to get the right to change a property (for instance, from the type '<immutable> directory' to 'directory'), and after that, the user may reset the type to its immutable version. Use of '<created-by-AccessRoad>': this start in a type signals an object that Access Road has created, for which no change and no deleting are allowed to the user.
The typed privilege manages some immutable access rights (it is a positive privilege) or some access restrictions (it is then a negative privilege) from a set of eligible parties or resources, as sources, to a set of resources or virtual folders, as targets. A source has rights upon a 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. One typed privilege is then designed to produce rights for numerous sources and numerous targets, but without ability to change them except from a straight deletion of the typed privilege. A typed privilege is created and deleted from its ACS. It handles immutable references to its sources and targets, and the rights cannot be changed after the creation. This is not the behavior of an AclEntry or a linked privilege. As a generic feature, a typed privilege cannot be inherited from the Resource or VirtualFolder parent. There are four types of typed privileges: simple, classed, specific and for an authorization server. A typed privilege contains one or more immutable rights which follow the rights list managed by the relevant ACS which manages this privilege. A typed privilege is registered by the program in the relevant sources and targets. They may be external ones (that is, their ACS is not the Privilege ACS) only for the authorization servers, and then the privilege is not registered in its sources and targets. If the concept of typed privilege is applicable, an access control may be simulated by Access Road by the mean of such an object, even if 'privilege' is not the term used in the software documentation. The linked privileges and the typed privileges are totally independent. Caution: the version 0.7 of Access Road fully implements only the simple typed privileges into the generic access path search.
This is displayed by a view when the rights are unknown. This excludes the cases where the rights are known to be null. This acronym is used rarely, only when a complex situation occurs beyond the modeling capacities of Access Road. This is implemented by the generic right '|unknown_rights|'.
<unverified right>
This is displayed by a view when the declared rights are unverified by a certification authority; this is a metadata added to the declared rights. This is implemented by the generic right '|unverified_rights|'.
This is an account in an Access Control System, as a kind of eligible party. Typically, each human user has a personal userID for logging in the operating system. Programs on a server have generally one or several dedicated accounts to run varied executables in the operating system.
This is a set of base objects, selected by the user, on which the searching of access paths is automatically processed by Access Road. It is associated to a diagram and to a text. The full view displays all the rights and relations, if any, between each couple of base objects in the view, by the mean of displayable links. The NoMore-NoLess view displays if a set of right users have their rights on a given access target, which fulfill or not the two more and less criteria.
A virtual folder is a folder of resources belonging to one ACS, responsible for being a privilege target, an alias or an alias reference. A virtual folder is also a right user since it manages a 'virtual member' type link to its members. The relation virtual folder/member is weak. On the contrary of a directory, deleting the container does not delete the members. There are two main types of virtual folders, where the members are always Resources, (1) for resource members which are not eligible parties and (2) for resource members which may be eligible parties. Thus, a virtual folder is an access target, and it is an access source only as reference of an alias or as container of its members. The default behavior in the rights propagation is the virtual folder transfers none of its rights, as target, to its members. An another ACS mode is possible, where the inverse rule is applied. Tree of virtual folders is a structural property of an ACS. There is no privilege rights inheritance in such a tree, but an ACS addon may change this behavior.
A B C D E G H I L M N O P R S T U V
®All
trademarks are property of their respective holders.
Copyright
2000, 2001, 2009, 2011, 2012 ACCBEE - All Rights Reserved.
Last
modification : 02 May 2012