SecureAuth Identity Store definitions

This topic covers terms and definitions used throughout SecureAuth Identity Store.

Deny List

Define words, fragments of words, and symbols not allowed in a user password. This applies to all or part of a password.

For example, the keyword "abc" when placed in a deny list and enabled on a password policy, disallows a user from creating a password like 123abc or 123abc456


The ending of a fixed period for which something is valid. In SecureAuth Identity Store, you can expire certain relationships. There are three ways to expire relationships: 

  • Expire user accounts – Useful for temporary workers or in situations where a user account has limited access.

  • Expire group membership – Let's say users are part of a group to help manage entitlements and privilege rights. For example, you might require user membership in this group to expire after 90 days due to temporary job assignments.

  • Expire privileges to a user – Privileges usually provide access to enhanced administrative functions. So, you might have a frequent requirement to only allow a user privileges for administrative activities for a period of time.


Think of groups as departments within your organization. Groups do not expire, but you can set an expiration date for members in a group.

Users who are members in a group can have certain privileges assigned to the group.

At this time, the Identity Store does not support nested groups. 

For example, use group privileges to grant users who are members of a group the right to manage users in another group.


Name of the user includes a combination of various name elements. It can be a salutation, first name, middle name, last name, and suffix.

To be clear, the unique identifier for the user is the Username attribute. 

For example, Mr. Frank N. Stein, Jr.

Password Policy

Define the password policy for users set up in the SecureAuth Identity Store. This includes the Deny List and password complexity rules.

You can define multiple password policies, but you only associate one password policy to each identity store instance. For example, you might have a certain password policy for the default identity store, and a different one for a secondary identity store.

If there are password complexity rules in the Identity Platform for applications that uses a SecureAuth Identity Store, it runs those password checks first before running the password checks from the Identity Store password policy.


A privilege defines what actions users can do to a particular resource. A privilege does not grant users access to take actions. To grant access to users, assign the privilege to a user or group.

Privilege actions include create, retrieve, update, and delete (CRUD) operations, as well as APIs for some of the objects. 

Each instance of SecureAuth Identity Store comes with the following system (static) privileges:

  • Admin – Allow all actions over branding, groups, users, and password policies.

  • Admin (read-only) – Allow admin read-only access to branding, groups, users, and password policies.

  • Developer – Can obtain and generate API credentials.

  • Group – Allow all actions to manage groups.

  • Help Desk ** – Allow all actions to manage user identities using the Help Desk through the Identity Platform.

  • IDS – Allow actions to administer the SecureAuth Identity Store database. All actions are allowed on cloned or new databases; the initial database cannot be deleted.

  • Owner – Allow all actions to maintain and administer the SecureAuth Identity Store database.

  • Preference ** – Allow all actions to administer preferences and branding.

  • Privilege ** – Allow all actions to manage privileges.

  • Resource ** – Allow all actions to administer user and group access to resources. Resources are defined in the SecureAuth® Identity Platform. For example, access to Salesforce.

  • User – Allow all actions to manage user identities.

   ** Privileges for future enhancements.  

Other notes about privileges:

  • Each new identity store instance comes with two dynamic privileges:

    • IDS Admin dynamic privilege to allow management of the identity store settings like identity store description, password policy, and so on.

    • IDS User dynamic privilege to allow management of users in the identity store (create, retrieve, update, delete).

  • Dynamic privileges are created when certain objects are created. And dynamic privileges are deleted when that object is deleted. For example, when you add a new group, it dynamically creates a group privilege. Then, you can assign privileges to that new group.

  • You can assign privileges directly to a group. Users who are members of a group get privileges assigned to the group.

  • You can assign privileges directly to a user. User can have a direct privilege to manage a group that they are not a member of.

  • When the same privilege is defined at the user and group level, the user privilege takes precedence over group membership.


User identities are typically consumers or employees of your organization. Employees could be permanent, temporary, seasonal, contract employees, or fall in other categories such as partners or manufacturers. You can include user identities that relate to service accounts, Internet of Things (IoT) devices, and any type of identity to manage.

User Status

The following explains the three primary user status codes (Staged, Active, and Deactivated) and how they relate to actions in the system: 


Status when user account is first created. Staged users cannot login.


User accounts become Active in any of these ways:

  • Include status value = active in the initial CSV file upload

  • Privileges to change user status to Active

  • Use the SecureAuth Identity Store API to set or change user status to active.

In Active state, user accounts could have the following statuses:

  • Locked – Status when user exceeds the configured number of login attempts defined by the password policy

  • Suspended – Admin can set status to Suspended. This pauses user account access to everything. This setting does not remove assignments and privileges. For example, use this to pause and later resume access for someone who is on a leave of absence.

  • Password Reset – User account has this status during one of these scenarios:

    • New account requires a password to be set for the first time

    • End user requests password reset

    • Administrator initiates password request for the user


Admin can set status to Deactivated.

In Deactivated state, user accounts could have the following statuses:

  • RTBF Requested – User account has this status during one of these scenarios:

    • Admin explicitly sets the state to RTBF (right to be forgotten) Requested

    • User requests this on their profile page by clicking Actions > Request RTBF

  • RTBF completed – User account has this status during one of these scenarios:

    • Admin explicitly sets the state to RTBF completed

    • When user chooses Request RTBF, system processes the request and sends a confirmation email to the requesting user.

User Type

User type identifies the relationship between the organization and the user. System values are:

  • Contractor

  • Corporation

  • Customer

  • Employee

  • External

  • Internal

  • Service Account

  • Temporary

  • Other


While most users have a "Name" and a "Username", these two have distinct uses. Username is a unique identifier commonly used to directly authenticate into a resource.

The Username is a required attribute that must be unique across the entire Identity Store database. The value is not case-sensitive and often equates with the user's work or personal email address. This field has no relationship to any of the user's associated emails.