Created attachment 1870001 [details] This is what the prompts actually look like Description of problem: We use the UserDirEnrollment plugin for automatic auth+enrollment in some profiles. However, the input field labels for this plugin do not reflect what our users must actually provide to be authenticated. In our use case we have the users authenticate with 2-factor credentials, PIN+Token. However, our users see a field instructing them to provide their LDAP password (which will not work). I have received several questions about this from my users during my dev deployment. Version-Release number of selected component (if applicable): rpm -q redhat-pki-ca redhat-pki-ca-10.12.4-2.module+el8pki+14018+adf6c54d.noarch cat /etc/redhat-release Red Hat Enterprise Linux release 8.5 (Ootpa) Actual results: There is no clear obvious supported way to customize the HTML Input Field Labels. Our users see a password field which instructs them to provide incorrect information. Expected results: There is a way to customize the text next to the input fields. Additional info: I am attaching screenshots illustrating the kind of customization we require to help our users be less confused. In RHCS v9 we accomplished this by manually overriding the /usr/share/pki/ca/webapps/ca/ee/ca/ProfileSelect.template file with our own javascript to "fix" field labels. This is not an ideal solution. The value of the field labels on the enrollment web pages seem to be populating from the CMS_AUTHENTICATION_LDAP_* variables in base/server/cmsbundle/src/UserMessages.properties. It would be nice if, for example, in the CS.cfg I could have configurable properties like this: > auths.instance.UserDirEnrollment.uidInputLabel=User ID > auths.instance.UserDirEnrollment.pwInputLabel=Two-Factor PIN+Token Which would be used to label the input fields as demonstrated in the attached screenshots.
Created attachment 1870002 [details] I'd like to label the inputs like this
At the very least, I need some kind of hacky not-ideal work around to fix these labels in the current version until a proper fix can get worked on. Many thanks!
I just noticed that in RHCS 9 we did this in a profile on a particular field input to set the input label: input.i2.class_id=genericInputImpl input.i2.params.gi_display_name0=Client Name (no app- prefix) .... input.i2.params.gi_param_enable0=true input.i2.params.gi_param_name0=sn_cert_name This demonstrates how we were able to label a *particular* field input label. When our users see this in the web browser they see a field labeled "Client Name (no app- prefix)" I would like to know how to do this with the "LDAP Password" input field.
In my original comment I said > [...] if, for example, in the CS.cfg I could have configurable [...] Upon reflection, this would be best if the configuration settings could be made on a per-profile basis. For example, I noticed in some profiles that very specific details about the parameters can be set: > caTokenUserSigningKeyEnrollment.cfg:policyset.set1.p1.default.params.ldap.ldapconn.secureConn=false I don't know how flexible this system is, or if my idea applies at all here. Is it possible to set default field labels for the LDAP Username/Password fields in the CS.cfg and then override them on a case by case basis per-profile? Here is my use case: 1. We have some profiles (most) they are for humans to use, the users enter their ID and 2-Factor Pin+Token 2. Some profiles are only for robots (service accounts) to use, the information entered is the robot UID and the static service account password Having these fields clearly labeled between profiles would improve our users' experiences and lead to fewer questions and errors. So in the case of #1 it would be ideal if we could use default labels from the CS.cfg In the case of #2 we would like to override those profile labels in the profile, for example (just making this up as I go along here): > auth.instance_id=UserDirAppEnrollment > auth.instance.UserDirAppEnrollment.uidInputLabel=Service Account UID > auth.instance.UserDirAppEnrollment.pwInputLabel=Service Account Password ---- If "inheriting CS.cfg defaults" and "overriding per-profile" is out of the question, I'd be satisfied with providing the uid/pwd input labels in each profile. Thanks so much!