Access Control Lists
From Cyclone3 Wiki
Access Control lists (ACLs) in the Cyclone3 Framework serve the purpose of user access rights management. By using these feautures the administrators can create even complicated hierarchies of user roles and permissions. Cyclone3 ACL is a combination of classical access control list (ACL) and role-based access control (RBAC)
Contents |
Design
Functions
Function defines an atomic data or operation of service. For example FNC_a401.data.article.title is defining manipulation on title of articles. And FNC_a401.action.article.enable is operation of service which allows to enable/disable article (also publish)
Roles
Roles represent single or grouped functions of the applications. Roles are also single units which can be assigned to groups and users. Roles were designed to represent real use cases in a hierarchical publishing environment such as a professional news portal. For example when user has role RL_a401.article.content, can manupulate with 'content' group of functions (manage title, subtitle, body and abstract of article)
Users
User is the elementary unit. A user is identified by a username and password and can carry roles from groups or direct.
Groups
As in many used filesystems, users can be organized to groups. A group can carry its own set of roles as well. In addition to user-defined groups there are global pre-defined groups which serve a specific purpose with a pre-defined set of roles:
- world
- By default every user is added to the world group and cannot be removed. The name 'world' is quite literal here. It really means the world - the Internet. A world-readable entity, if it is published, is readable by web page visitors.
- admin
- This special group entitles its members to do anything (role RL_unlimited). Similar to the root user on *nix systems. This special group is also used to add and removed users.
- editor
- The default group for editors. This group by default has the right to create and publish entities. User in group editor is able to login into XULadmin, also has role RL_login.
ACL roles
ACL roles are special states of users related to entity. For example default user related to article is 'owner'. ACL roles can extend permissions (yes, owner can more things with own articles than other users :)
Permissions
For every group and user the entity recognizes 2+1 permission bits: read, write and execute.
- read
- For an entity, this means viewing/opening the entity. This also replaces the execute bit in case of directories - opening a directory means listing the contents. For a role the read permission makes sense when the role can be used in a read only manner. Such as the ability display users details, but not change them.
- write
- Editing and saving an entity. In the role context it means executing a role with write privileges.
- execute (not currently implemented)
- The execute group is currently not implemented - the bit exists in the database and can be set in future, but it is neither used nor displayed.
Applying the permissions is carried out in 3 steps:
- General groups permissions are read (world, editor, admin). If the user is in the admin group, the check ends here and the user receives all permissions.
- The list of custom user groups is cycled through and permissions are applied incrementally.
- Individual user rights are applied. The individual rights override group rights even in case of decrementing the permissions.
ACLs in XULAdmin
In Cyclone3 XULAdmin the ACL (Security) tab can be found in the properties' for any user, group or entity in the System tab. The use depends on the context.
In the user/group context it means adding/removing roles and role permissions to a user or a group.
In an entity context, different groups and users, apart from the owner can be added to an entity. Then, specific roles and permissions for this entity can be set for invidual groups and users.
Examples
- A news portal wants to have to groups of people. Authors will be able to create and edit new articles but will not be able to publish them. The articles are published only if approved by an Editor. The solution: Create groups for both authors and editors. Grant read and write permissions on the role RL_a401.article.content to the authors group and role RL_a401_article.publishing to the editors group. Note that it is possible to be able to publish an article and be unable to edit the article at the same time.
