Issue with creating operator ID with a hyphen
You are using External Authentication for PRPC using the WebLDAP1 rule. This works fine and authentication with ActiveDirectory server works fine too. However, when trying to create a user that contains a hyphen in the username, this is refused.
The usernames cannot be converted to include underscore, instead of hyphen, because the users already exist in ActiveDirectory. The users are already part of an authentication strategy and SSO approach with multiple other systems.
"In addition to letters and digits, the identifier can include the following characters: period, single quote, tilde(~), underscore, exclamation point (!), ampersand (&), octothorpe (#) and no more than one @ character. Don't use forward slash or backslash characters in the identifier."
Steps to Reproduce
Consider an operator that worked OK and SaveAs with the new Operator ID as "r.otsmane-elhaou" to observe the issue.
The product is restricted to validate an Operator ID for inclusion of characters including ‘-‘.
There are no plans to change this within PRPC 6.x as the scope of changes required to include the character is not known. Also, class names use ‘-‘ character which may present conflicts when using refactoring tools.
The work around is achieved with below steps for operators with hyphens:
1. Create an operator in Pega with each hyphen substituted by underscore as hyphens are not allowed in operator name.
2. On login screen, operator enters the company email and network password (enter as hyphen only). As the operator is enabled with external authentication, it will be authenticated by LDAP. The OOTB "AuthenticationLDAPVerifyCredentials" activity is called.
3. Override this activity with one additional step that converts from hyphen to underscore.
- Change the value of param.UserIdentifier to @(Pega-RULES:String).replaceAll(param.UserIdentifier,"-","_") before it do Obj-Open.
- Override this at organisation level, if all Pega applications in the organisation use LDAP authentication. If it is specific to an implementation, do it in implementation layer.
4. As this activity got overridden, it should become part of the rules being called during authentication.
5. Change BROWSER requestor type prpc:unauthenticated to an access group having access to this activity.