Accounts and Roles
If your application uses Windows Security Integration, refer to implementation notes in the topic: Windows Security Integration
When security is enabled, everyone who uses the application must have an account. The account is used to identify and authenticate the user, hold the list of granted privileges, and store features that are unique to the user such as a custom automatic sign out period.
Use care with special characters in account names and passwords. While valuable from a security standpoint, some characters may cause problems with certain Alarm Notification devices.
It has been reported that an @ symbol (and possibly others) in a password will not work with the Twilio® interface.
Reopen the Accounts Dialog (one of several ways)
Features of an account:
It's easier to work with one section of this dialog if you minimize the other sections.
General section
Realm: Only if realm logins are enabled. Identifies the user's realm.
Username: Identifies the user.
Password section
Password: Used to authenticate the user.
Force Reset: When creating accounts for operators, it is standard to require that they change their password on first sign-in.
Advanced section
Disable option: Prevent sign in without deleting that account.
Alternate ID: For installations that include the Alarm Notification System. The numeric password they will use when signing in by phone.
Default sign out time period: Set between 0 and 720 minutes if the default time period does not apply to this user. Zero means no automatic sign out.
Privileges section
Roles: The "job descriptions" that apply to the account.
Privileges: Additional rights specific to this one account.
Recommended practice is to assign privileges to roles, then assign roles to accounts.
A sample Accounts dialog after the first account is created.
If security realms are enabled, managers who members of a realm can see only those accounts and roles that are within the same realm.
If using security realms, it is important that you keep one manager account with no realm membership.
Similar to an account, but defines the privileges required by a job description rather than defining an individual. Account management is greatly simplified by defining roles for tasks, then assigning those roles to accounts. Changes made to a role are applied immediately to the accounts that hold the role.
You can assign roles to other roles, and multiple roles to an account. Privileges are additive, meaning that the account will gain all privileges defined in all assigned roles.
It is not possible to sign into an application using a role.
To help you configure a new application, several roles are built in.
For sites using Security Realms, you have the option of making roles at the root level visible to all realms. Doing so can greatly reduce the number of roles you need to create for your various realms.
Otherwise, managers within a realm can see and assign only those roles that are part of their realm.
Features of a role:
- Realm: Only if realm logins are enabled. Identifies the role's realm.
- Name: Identifies the role. Roles have no other authentication information.
- Description: Contextual information about the role. May describe the role's intended use.
- Disable option: Immediately removes the privilege set from all accounts that have this role, without needing to delete it. You cannot assign a disabled role to accounts.
- List of assigned privileges and roles, and the tag or workstation scope that those apply within.
Default privileges for the Operator role
The predefined roles:
Privileges associated with the built-in example roles.
