If you implement LDAP authentication, the login process accesses a central LDAP directory for authentication and ignores the password in this Operator ID instance. However, an Operator ID data instance is still needed for each user.
When a requestor logs in, the extension point activity Code-Security.ApplicationProfileSetup runs as a late step. The standard activity with that name is an empty stub. Your application can override the standard activity to perform additional processing as required.
Using the optional security audit feature, your application can present in the History Details information about which values were added, updated, or removed from an Operator ID instance.
Operator ID passwords are saved as hashed values in the PegaRULES database, using the bcrypt (default) algorithm. Two property types are used when changing the password, Password type for the New Password field, and Text type for the Confirm Password field. The Data-Admin-Operator-ID.pyPwdCurrent property stores the entered password after it is validated.
See Configuration Settings Reference, on the PDN, for details on this and other crypto settings. See Property rules — Implementing and using the TextEncrypted type for more information about the Password property type.
During login, the system copies most properties from the Operator ID instance to properties in the pxRequestor page of the clipboard. For browser-based users, this information is also on the OperatorIDpage.
However, the value of the password property pyPwdCurrent is always encrypted both on the clipboard and during log-in.
Standard login processing does not limit the number of sessions that one Operator ID can have open. In practice, the system cannot reliably detect when a session ends, so internal records of which Operator IDs have activity sessions might overstate the true situation, and wrongly prevent users from an additional login.
After you save a new or updated Operator ID instance, the change might not be reflected on another node in a cluster until the Pega-RULES agent on that node performs the next system pulse — typically after no more than 60 seconds. Unlike instances of most other Data- classes, the system saves Operator ID instances to the rule cache. As a result, until the next time the rule cache is synchronized, one node might access a stale copy from its rules cache.
The system maintains the property pyLastSignon as the date and time of the last successful login (using normal authentication) by this Operator ID, using a Declare Trigger rule. (Ordinarily, do not update this property value directly in your application.)
You can create Operator ID instances by importing a comma-separated values (CSV) file, such as created by Microsoft Excel. For an example, search for "Bulk Operator Load" in the Pega Exchange area of the PDN. You might need to adapt and extend this example to meet local requirements.
Deletion of an Operator ID instance is not allowed when there are open assignments on that operator's worklist, or when that Operator ID is referenced in another data instance (such as an organization unit or workbasket).
However, if a user is no longer active, rather than deleting the Operator ID instance, you can follow these steps:
You cannot delete an Operator ID if the operator has rules checked out. The operator must delete or check in all rules in their personal ruleset.
|
|
division, organization, role, rule cache, RuleSet list |
|
|
Atlas — Initial Operator IDs |