The Quasar UI features a customisable role-based access control system. Users are tracked and ‘logged-in’ via their Active Directory domain accounts, provided the AppPool account and IIS server hosting the Quasar UI, are running under domain accounts.

Users will not have to explicitly log in if they are already logged-on to the domain on their workstations and their browser is configured to treat the Quasar UI as an Intranet Site. Other users will be presented with a login dialog as usual.

User access to various parts of the Quasar UI is controlled via the user’s AD groups combined with certain settings in ui.cfg.

NOTE: The AppPool must be recycled to reload ui.cfg after configuration changes are made.

For the RBAC system to be active, the rolesec setting must be true in ui.cfg.


Built-in Roles

There are two types of roles in this system: built-in, and customisable.

The built-in roles are hardwired into the application, and consist of the following: BasicAccess This role allows users to access the web UI. A user without this role will not even have permission to access /. WriteAccess This role allows users to make POST queries. A user without this role can view information but cannot make any changes to the system.

Custom Path-Access Roles

The customisable roles can be created / edited in ui.cfg, and mapped to URL-path whitelists.

For example, if a certain URL-path has a role associated with it, the user must possess that role in order to successfully access the URL-path, otherwise they will get a 403 error.


There are two mappings, defined in ui.cfg, that drive this process.

  • The first is a mapping of role names to Active Directory group names. (ADRoleMap in ui.cfg)
  • The second is a mapping of role names to URL-path regular expressions for the customizable roles. (PathRoleMap in ui.cfg)

Security Process

The RBAC security process works as follows:

  1. A user accesses the UI, and Windows/IIS provides the UI with the user’s details.
  2. The UI queries Active Directory for the given user’s AD Groups. Group queries are cached by the UI app to ensure that the AD/DCs are not flooded with group queries.
    The validity time for this cache is controlled by the ADCacheTime setting in ui.cfg, documented below.
  3. The user’s AD group names are mapped into role names using the first mapping (ADRoleMap).
  4. The UI checks the user’s roles against the built-in roles – BasicAccess and WriteAccess. If the user does not possess these roles, a 403 error is returned and the user is denied access.
  5. The UI takes the requested URL path, and maps the path into the needed roles for the path using the second mapping (PathRoleMap).
  6. The UI compares the user’s roles from (3) against the path-required roles from (5). If there are matches, the operation is allowed to continue.
    If there are no role matches, a 403 is returned and the user is denied access.

Configuration & Testing Process

The following is the recommended process for configuring and testing the RBAC component:

Note: Remember to recycle the AppPool after changes to ui.cfg.

  1. Set rolesec to false. Access the UI with a local user, and verify all is working correctly.
  2. Set rolesec to true and ADCacheTime to 0. Setting ADCacheTime to 0 forces an AD query on every access. This is recommended for testing when adding groups to users during install / user setup phases.
  3. Attempt to use the UI as a selected AD user who has none of the configured groups assigned. Verify that the user is forbidden access.
  4. (Have your AD admins) Add relevant AD groups to the selected user.
  5. Re-test using the UI as the selected user (from step 4 of the Configuration & Testing process). Verify that the user is now allowed access.
  6. Perform similar tests for users with other configured levels of access (WriteAccess, customized roles, etc) until satisfied that the security controls are working as configured.
  7. Once satisfied that the security is working as configured, set ADCacheTime to a sensible time in seconds. The ADCacheTime represents a tradeoff between load on the AD servers / network for queries, and time for a user’s AD group changes to take effect from the POV of the Quasar UI.
    We recommend 300 (5 minutes) as a usually-acceptable compromise.

NOTE: These basic security controls apply to use of the UI only, and care should be taken to ensure access to the backend SQL DB is secure also – anyone with direct access to the underlying SQL DB can bypass these security controls.