Users and Roles
Open-AudIT has moved away from providing access via the group system to a more flexible system using Roles.
A Role contains a set of permissions (create, read, update, delete) for endpoints (devices, locations, scripts, etc).
A User in Open-AudIT is a member of one or more Roles.
There are four roles provided with Open-AudIT. These can be changed and new Roles created.
An example of a database record for a Role is below (in this case, the org_admin Role).
A user record from the database is below (in this case the Admin user).
You can see the roles that this user has (admin * org_admin).
There is a routine in Open-AudIT that takes a user's details and the action they are requesting and compared the permission required by that action to the list of roles the user has. A response of true/false is provided and the user is allowed (or not) to proceed.
In Open-AudIT each endpoint and action has an associated permission. These mostly translate 1 to 1 with functions. IE - devices::create action would need the devices::create permission. There are a few places where this does not match 1 to 1. For example report::execute. There is only create, read, update and delete permissions. In the case of execute, depending on the endpoint, it is mapped to update or read. In the specific case of report::execute, it is mapped to devices::read. These are detailed on the individual endpoint wiki pages.
In addition to the above Users and Roles, we also have organisations.
Every endpoint (with a few exceptions) now has an Organisation associated with it. This field in the database is always called org_id.
A user has access to a list of organisations as part of their account. This is visible in the database as the orgs column in the users table (currently oa_user).
When a user requests an action, in addition to the role based access above, another check is performed to determine if the user has access to the item based on it's org_id.
Organisations are store in a tree like format. Each organisation has a parent. In the case of the default Org, it has itself as the parent.
If a user has access to an Org, that user also has access to any of that Orgs descendant's. There is no need to select every Org for a user. Only the highest level Org need be selected and at run time the descendant's are determined. If the user has access to the Org directly (is, in their database record) or they the requested Org is a descendant of an Org the user has access to, their access is granted. There is no limit to parent, child, grandchild, etc. If the requested item has an org_id that is a descendant of the users Orgs, the user will be allow to access.
Active Directory (AD) can be used in conjunction with RBAC. Each Role has an associated AD group name. When a user log's in to Open-AudIT using AD, if configured to do so, Open-AudIT will ask AD for a list of groups the AD user belongs to. If the AD user belongs to a group with the name required by the role, that Role is associated to that Open-AudIT account.
In this way it is even possible to not set up any additional users in Open-AudIT, configure the Roles and AD within Open-AudIT and place AD users into the required AD groups and they will be able to log on. Open-AudIT will verify the users name and password using AD (as it did previously), check the roles and if they have at least one role, will create them an Open-AudIT account and log them in.