This article discusses security roles and permissions for Identity Panel.
This content applies to version 3.3 and greater. This content applies to both cloud and on-premise versions.
Overview
Security Roles are divided into the following sections:
- Attribute Permissions – Limit access to Identity data at an attribute level
- Features – Enable user interface features (has no impact on REST API security)
- Data Permissions – ACLs for access to data. These are applied to the REST API level, and are also bound to the database access library.
Default Permissions
Identity Panel has four default built in roles with the following permissions:
Admin
The admin role is a special case which permits assignment of security principal, but prohibits changing of permissions. This is a safety feature to prevent accidental removal of effective admin access.
The admin role has Read/Write/Execute access to all object types, and has access to all UI features and all attributes.
Note: deciphering a password stored in connection settings requires Execute access for JsonSettings. By default, only Admin and Writer have this permission.
Writer
The writer role is a special case role that also prohibits changing of permissions. It has sufficient permissions to perform all tasks available to Panel Tools.
This means it includes data permissions equivalent to admin (Read/Write/Execute for all object types), but has zero browser UI features.
User
The user role may be customized. By default it grants read access to all user interface features except for settings.
The user role also has the following permissions:
| Permission | Scope | Purpose |
|---|---|---|
| Write ReportRecord | N/A | Allows users to write the cache record required to be able to generate and view reports |
| Write WorkflowRecord | LinkAuthorized(context) | Grants write access to a workflow if the API request context is a valid enciphered step queueing link (as embedded in an email by the Link() function) |
| Read * | Read all objects and attributes |
Everyone
The everyone role may be customized. By default it grants no access to all authenticated users.
Additional Roles
The following are sample permissions matrices for additional access.
Schedule Manager
The schedule manager role has permissions to view and run schedules on the dashboard and edit schedule settings. It may be combined with the default users role or other roles to expand access to run history or object data.
Features: Mode = Allow
- Dashboard
- Settings
| Permission | Scope | Purpose |
|---|---|---|
|
* (Read/Write/Execute) |
N/A | Allows users to read, write, and execute schedule settings objects (Schedule), schedule execution tracking artifacts (ScheduleInstance, StepInstance), and schedule run history (ScheduleRecord) |
| Write WorkflowRecord | LinkAuthorized(context) | See User role |
| Write JsonSettings | Id == "Schedules" | Write global schedule settings (to enable and disable schedule engine). |
Report Readers
The report readers role may generate and view reports.
Note: the following definition does not grant access to the data required to build a report. That should be scoped via other roles.
Features: Mode = Allow
- Reports
| Permission | Scope | Purpose |
|---|---|---|
|
* (Read/Write/Execute) |
N/A | Allows users to manage temporary report caching objects |
| Read Report | N/A | Allows users to read report definitions |
Report Writers
This role has access to generate reports as well as edit all report settings.
Note: the definition does not grant access to the data required to build a report. That should be scoped via other roles.
Features: Mode = Allow
- Settings
- Reports
| Permission | Scope | Purpose |
|---|---|---|
|
* (Read/Write/Execute) |
N/A | Allows users to manage temporary report caching objects |
| * (Read/Write/Execute) Report Report - All |
N/A | Allows users to read/create/modify report definitions. The Report - All permission explicitly includes reports that are otherwise assigned to a specific security role or user profile. |
Inherent Permissions
Because all database queries are subject to permissions control, some permissions are inherently held by all authenticated access to enable the product to function. For these data types security is applied at the API level, or through only being accessed internally within Identity Panel.
These data types are enumerated because they are listed in the security role interface, but changes to reduce access will be ignored.
The following are "Un-scoped Access" permissions.
Read
- AttributeNameMap – data structure to support serialization of attributes. Not exposed to direct access by any API
- FieldMap – internal tracking data structure for full-text search indexing, not exposed by API
- JsonSettings – read access to JsonSettings is required, among other things, to read security roles
- DataLock – internal system object for locking, not exposed by API
- User – internal data structure to track user profile details, API exposure is limited to the current logged on user
- Tenant – internal data structure to track database and full-text connection strings, not exposed by API
Write
- AttributeNameMap – see above
- LogMessage – All requests have write access, for example to log errors. Read access on the API may be security scoped.
- AccessLog – All API requests are added to the audit log collection. Read access on the API may be security scoped.
- DataLock – see above
- User – see above
- Tenant – see above
- SearchQueue – all data which is indexed for full-text search is written to search queue. This is not directly exposed by API
Posted to Twitter @IdentityPanelKB of June 12, 2017
Comments
0 comments
Please sign in to leave a comment.