Panel platform uses role based security, granted through IIS authentication. When using Windows Integrated authentication security, roles are mapped to security principals such as domain security groups, local groups, or login IDs based on group sids. When using federated authentication, security roles may be mapped to "Name" or "Role" claims.

When Panel platform is installed four default roles are created:

  • Admin: This role has permission to do anything in Panel platform, and is pre-initialized to the logged in user when the first license is claimed.
  • Writer: This role has permissions required by the SoftwareIDM Panel Service.
  • User: This role has read-only access to the Panel platform web application. The User role is not assigned a security principal by default.
  • Everyone: The everyone role is able to log in to the application but is not able to do anything. This role is pre-initialized to authenticated users.

Security roles are evaluated at the database level, the API level, and the user interface level. Security roles control access to data attributes, Identity Panel UI features, and individual object type ACLs.

When a user's session is established on login, Identity Panel iterates their role memberships, and constructs a virtual role representing that user's level of application access. The user is then authorized against this virtual role on every REST API request. When the web application is loaded, the virtual role is embedded as a javascript object so that the UI code can choose which interface elements to show.


Identity Panel allows new roles to be created and existing roles to be modified using the Security settings tab. Although security settings allow the Admin and Writer security principals to be changed, the details for these roles are protected from modification. This is to prevent accidental application lockout.

Basic Roles

Each role has the following settings:

  • Security Principal
    This setting determines what security principal is associated to this role. In most cases the security principal should be an Active Directory security group. Type the first three letters of a group name to trigger the auto-complete menu. for AD authentication, the auto-complete menu uses an LDAP search which is set up in config.json.
  • Default Shutter View
    The default shutters view setting is more about convenience than security. It can be used to apply custom silo and attribute filtering to the UI as a convenience for less technical users, see Shutter Views.
  • Attribute Security Mode
    This may be set to Grant All, Grant Selected, Deny Selected, or N/A. These settings allow granular control of attribute-level security. A setting of N/A is equivalent to Grant Selected without any attributes chosen. The typical choice for a limited role is "Deny Selected".
  • Attributes
    This multi-select allows you to enter a list of attributes to be granted or denied. Note: if a user is a member of two roles, the more permissive role will always be chosen. For example, if a user has "Grant All" from the Admin role, and "Deny Selected" from the User role, the resultant privilege will be "Grant All".
    The attribute select box in Role Security does not enable attribute name localization. This makes it possible to determine which attributes have been granted or denied, even when different attributes have been normalized to the same name.
  • Feature Security Mode
    Like with attributes, this can be set to Grant All, Grant Selected, or Deny Selected. The typical choice for a limited role is "Grant Selected". As with attributes, the resultant access will be the most permissive combination of a user's roles.
  • Features
    This is a list of web interfaces to enable for a user.

Role Settings

Data Permissions

In addition to attribute security and user interfaces, security roles have data permissions. These permissions are applied at the data access layer, so they affect all aspects of API access.

Role Data Permissions

A data access permission has four parts:

  1. Mode – Either "Allow" or "Deny", indicates how the ACL affects permissions.
  2. Access Granted – May be "Read", "Write", "Execute" or "*". The read and write permission apply to the ability to access data from the database. The Execute permission is really only applicable to schedules and workflows.
  3. Resources – May be a list of object types or "*". This represents the objects included in the ACL. Typically it is scoped by object type, which maps onto a data collection.
  4. Scope Rule – Advanced customization may be performed using a scoping rule.
    If a scoping rule is specified, the rule is applied to each object being considered for authorization. The authorization will fail unless the rule returns true for that object.
    In the example above, a scoping rule is used to allow everyone in the User role to make changes to Workflow objects, but only if the change being made is an invocation of a ciphered workflow link. Another possible use of scoping rules would be to segment data by market or business unit.

Copyright © SoftwareIDM

Table of Contents