Question
CGI
IN
Last activity: 25 Feb 2016 9:00 EST
Disable Standard Login in Production
User Story:
We need to disable standard login in PROD. Access to all standard(default) users shipped with PEGA should be disabled in Production, except [email protected]. This is to make sure prod is only accessed through SSO/LDAP.
Suggestion: I have already suggested to check the “Use external authentication” check box in “Security” tab of Operator profile, so that user can Login in Production using SSO/LDAP only.
Could you please suggest the options to achieve above User Story.
Accepted Solution
Updated: 22 Feb 2016 9:01 EST
Pegasystems Inc.
US
Hi Rajasekhar,
The Activity Code-Security.ApplicationProfileSetup is now run after authentication and also each time a PRPC Thread Page is created. The document on PDN was written at the time for PRPC 5.5SP1 and does need to be updated. You could still proceed with this method but since the user is authenticated at the time the activity is run you may not want to.
Back to your requirements.
Currently you're trying to use two types of authentication:
PRCUSTOM - For LDAP authentication
PRBASIC - For standard login but only for admin users etc. There are extra requirements here that you have provided.
The problem is PRBASIC authentication is not modifiable so you're just going to keep running into problems with the extra requirements . It's the OTB authentication that has very little customization that you can put in.
Possible Solution:
PRCUSTOM - For LDAP authentication (Use Externally Stored Credentials)
PRCUSTOM - For standard login for admin users. (Use Credential Stored in PegaRULES)
There is a setting on the Data-Admin-AuthService on the Custom tab for "Source of Operator Credentials" that can be set to "Use Credential Stored in PegaRULES" or "Use Externally Stored Credentials". This will allow you to separate your two authentication types while having greater control on the admin logins. The admin users can still have passwords kept in PRPC and the login activity is very simple.
Hi Rajasekhar,
The Activity Code-Security.ApplicationProfileSetup is now run after authentication and also each time a PRPC Thread Page is created. The document on PDN was written at the time for PRPC 5.5SP1 and does need to be updated. You could still proceed with this method but since the user is authenticated at the time the activity is run you may not want to.
Back to your requirements.
Currently you're trying to use two types of authentication:
PRCUSTOM - For LDAP authentication
PRBASIC - For standard login but only for admin users etc. There are extra requirements here that you have provided.
The problem is PRBASIC authentication is not modifiable so you're just going to keep running into problems with the extra requirements . It's the OTB authentication that has very little customization that you can put in.
Possible Solution:
PRCUSTOM - For LDAP authentication (Use Externally Stored Credentials)
PRCUSTOM - For standard login for admin users. (Use Credential Stored in PegaRULES)
There is a setting on the Data-Admin-AuthService on the Custom tab for "Source of Operator Credentials" that can be set to "Use Credential Stored in PegaRULES" or "Use Externally Stored Credentials". This will allow you to separate your two authentication types while having greater control on the admin logins. The admin users can still have passwords kept in PRPC and the login activity is very simple.
Instead of going back and forth even more in a Mesh post I have written a demo that implements this solution. If you want I can show you what I have and we can collaborate on getting it to work the way you want. I am 99.999% sure I have and can matched all your requirements. Once done I can export the solution and provide a ruleset to you that you can refactor and implement on your end. (Also I will document the end solution here for others)
If you want to do this send me an email, [email protected] and let me know when you have time.
Virtusa IT Consulting
AE
Hi Rajasekhar,
If you check for 'Use external authentication' in Operator rule then the context URL will be different for that operator it will be something like 'http://localhost:8080/prweb/PRWebLDAP1' where that operator can login, since that operator would require 'PRCustom' type of authentication for login and to achieve this we need LDAP lookup for login. So, no standard (default) user will be allowed to login with '/PRWebLDAP1' context URL unless you authenticate that user from LDAP server.
You need to create an Authentication service with authentication type as 'Custom', and you can achieve this with 'Create authentication service' wizard on 7.x version by navigating as Designer Studio -> Org & Security -> Authentication -> Create Authentication service
Thanks,
Habeeb Baig
CGI
IN
Thanks Habeeb,
Query: How to restrict user access to LDAP/SSO only. It should not allow any other user, if the profile is present in Production system i.e. excluding .[email protected]
Pega Systems
IN
Phani Sahukaru can you help point to the right person to answer this query?
Virtusa IT Consulting
AE
Hi Rajasekhar,
If you want to block some operators then you can have a 'Access role to object' ARO where you can control the access to that operator by giving values from 0 or blank to 5, 0 or blank as 'No access' and 5 as 'Production'. 5 is the highest value which will allow the user to have access through all the environments. You may use 'Data-Admin-Operator-ID' as your access class.
An ARO rule will look as below in the 'Security' category.
Thanks,
Habeeb Baig
Citicorp Services India Private Limited
IN
Hi Rajasekhar,
Once the user clicks login, the Custom authentication activity would get executed. This activity will check for the of Organization / Organization Div / Organization Unit values for the user in both LDAP and PRPC. If there is a mismatch then the operator would not be allowed to login.
Since [email protected] operator use different Organization mapping than your application user's Organization mapping , we can't let [email protected] to login.
It is recommended to use http://<servername>:<port>/prweb/PRServlet context to login with [email protected] operator.
Please let me know if this helps.
Thanks,
Gowrishankar.
CGI
IN
Hi Gowrishankar,
Requirement is "We need to disable standard login {http://<servername>:<port>/prweb/PRServle} in PROD. Access to all standard(default) users shipped with PEGA should be disabled in Production, except [email protected]. This is to make sure PROD is only accessed through SSO/LDAP".
Lets assume, there are 2 operator similar configuration profile in system with “Use external authentication” check box in “Security” tab unchecked.
System access url is http://<servername>:<port>/prweb/PRServlet
Hi Gowrishankar,
Requirement is "We need to disable standard login {http://<servername>:<port>/prweb/PRServle} in PROD. Access to all standard(default) users shipped with PEGA should be disabled in Production, except [email protected]. This is to make sure PROD is only accessed through SSO/LDAP".
Lets assume, there are 2 operator similar configuration profile in system with “Use external authentication” check box in “Security” tab unchecked.
System access url is http://<servername>:<port>/prweb/PRServlet
When [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, it should display message to login with SSO/LDAP. But when [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should able to login.
Query is How to restrict [email protected] from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP.
Thanks in Advance
Regards
U Rajasekhar
Pegasystems Inc.
IN
Hi Rajasekhar, Good morning!
could we refer to https://community.pega.com/sites/default/files/help_v719/procomhelpmain.htm
Please share your thoughts/comments, Thank you!
psahukaru
CGI
IN
Thanks Phani,
My query is different. We need to disable standard login in PROD. Access to all standard(default) users should be disabled in Production, except[email protected]. This is to make sure PROD is only accessed through SSO/LDAP".
Thanks Phani,
My query is different. We need to disable standard login in PROD. Access to all standard(default) users should be disabled in Production, except[email protected]. This is to make sure PROD is only accessed through SSO/LDAP".
- we need to restrict all user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP.
- when [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should able to login
Note: When user try to login using http://<servername>:<port>/prweb/PRServlet. Once user enter User name and password and clicks Login In button, we need to display message to use SSO/LDAP url for login. Can someone guide me how to custimze or which rule needs to be updated.
CGI
IN
Hi Bhaskar,
Could you please share the details
Note: when [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should only able to login
Thanks in Advance
Regards
U Rajasekhar
Pegasystems Inc.
US
Hi Rajasekhar,
Taking your requirements:
- we need to restrict all user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP.
- when [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should able to login
You will need two servlet definitions because your SSO/LDAP is going to require user login where passwords and possibly even user definitions are not maintained in PRPC, not the system of record. The administrators will have their passwords maintained in PRPC as they are not accessing the application via SSO/LDAP. The administrator user(s) are for PRPC administration and probably don't correspond to user records defined in the LDAP server.
Hi Rajasekhar,
Taking your requirements:
- we need to restrict all user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP.
- when [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should able to login
You will need two servlet definitions because your SSO/LDAP is going to require user login where passwords and possibly even user definitions are not maintained in PRPC, not the system of record. The administrators will have their passwords maintained in PRPC as they are not accessing the application via SSO/LDAP. The administrator user(s) are for PRPC administration and probably don't correspond to user records defined in the LDAP server.
- /thread/http:http://http://<servername><port>/<servername>:<port>/prweb/PRWebLDAP1 - This is for SSO/LDAP [AuthenticationType=PRCustom]
- /thread/http:http://<servername>:<port>/prweb/PRServlet - Standard login [AuthenticationType=PRBasic]
LDAP/SSO Configuration:
- You will need a Data-Admin-AuthService record for SSO/LDAP and the Web.xml already defines a servlet for PRWebLDAP1: ServletName=WebLDAP1, AuthenticationType=PRCustom, AuthService=WebLDAP1. So your Data-Admin-AuthService name would be WebLDAP1 in PRPC.
- In the Data-Admin-AuthService there is a setting on the custom tab of the Data-Admin-AuthService record: Source of Operator Credentials. Set this setting to "Use Externally stored credentials". This forces all users who access the application via prweb/PRWEbLDAP1 to have the "Use External Authentication" flag in their Data-Admin-Operator-ID record.
- Start with Code-Security.AuthenticationLDAP as the Login activity for the AuthService. Add customization if any to Code-Security.AuthenticationLDAP and AuthenticationLDAPVerifyCredentials.
- OTB the AuthenticationLDAPVerifyCredentials activity will set the pyImportedUser property to "true" if the user credentials have been accepted by the LDAP server. (Step 10 in PRPC 7.7+ but has always been there)
Results:
- Any user who has the "Use External Authentication" will not be able to access /prweb/PRServlet. There is a PRPC password stored with these users, usually taken from a model record etc. This is not known to the user but even if they did figure it out we still don't allow access, they would get an error: "This user must use external authentication"
- Any user who DOES NOT have the "Use External Authentication" will not be able to access the system via /prweb/PRWebLDAP1. If they get past LDAP authentication they will still get an error "This user must use internal PegaRULES authentication".
- If a user like [email protected] does not have the "Use External Authentication" checked then they will be able to access the system via /prweb/PRServlet. (There password is stored in PRPC)
Note: There is no way to change the error messages "This user must use external Authentication" and "This user must use internal PegaRULES Authentication". We should change these to field values.
Hope this gets you on the right track.
--Chris
CGI
IN
Thanks Chris.
I understand Point 1 and 2 mentioned above.
Query: If a user like [email protected] does not have the "Use External Authentication" checked and password is stored in PRPC. If we have to restrict from access the system via /prweb/PRServlet. How can we do it?
Thanks in Advance
Regards
U Rajasekhar
Pegasystems Inc.
US
Hi Rajasekhar,
Query: If a user like [email protected] does not have the "Use External Authentication" checked and password is stored in PRPC. If we have to restrict from access the system via /prweb/PRServlet. How can we do it?
Here you have a user defined that can ONLY access the system via /prweb/PRServlet. Furthermore, this user configuration has restricted the user so they can't access /prweb/PRWebLDAP1, SSO/LDAP authentication. You would have to update their operator record and check the "Use external authentication" to not allow the user to access via /prweb/PRServlet and allow access via /prweb/PRWebLDAP1. It's one or the other.
At some level you will need to have an administrator make sure user records are set properly in Production. You can't customize the PRBasic authentication type, the default setup for prweb/PRServlet. You can enable advanced security policies for users who access the system through standard PRPC login.
Note on LDAP/SSO:
Hi Rajasekhar,
Query: If a user like [email protected] does not have the "Use External Authentication" checked and password is stored in PRPC. If we have to restrict from access the system via /prweb/PRServlet. How can we do it?
Here you have a user defined that can ONLY access the system via /prweb/PRServlet. Furthermore, this user configuration has restricted the user so they can't access /prweb/PRWebLDAP1, SSO/LDAP authentication. You would have to update their operator record and check the "Use external authentication" to not allow the user to access via /prweb/PRServlet and allow access via /prweb/PRWebLDAP1. It's one or the other.
At some level you will need to have an administrator make sure user records are set properly in Production. You can't customize the PRBasic authentication type, the default setup for prweb/PRServlet. You can enable advanced security policies for users who access the system through standard PRPC login.
Note on LDAP/SSO:
When using LDAP you can/should take the approach that PRPC is not the system of record for the users. I used this approach for every external authentication configuration I setup out in the field for many years. So when you start out in production the SSO/LDAP users are not defined in PRPC yet. You just have user model records based on PRPC usage; user, manager etc. As users login you map user data from LDAP to user model records in PRPC and the login process adds the PRPC operator record for you with the pyImportedUser property set to true. This is handled pretty much OTB in the Code-Security.AuthenticationLDAPVerifyCredentials but it's expected you may need to customize this to meet you needs, what users get mapped to what model records. You never have to issue an obj-save of a operator record during SSO/LDAP authentication in PRPC, the engine handles it for you. It adds or updates the Data-Admin-Operator-ID record with each login. So even as things change at the LDAP level, say someone gets married and changes their last name, then this becomes reflected in PRPC operator record when the LDAP user attributes are updated. If a user gets promoted to manager and the LDAP attribute changes then the next time they login to PRPC this can be reflected automatically. This then makes it so users are administrated in one spot, the LDAP server.
With this approach no one has to admin the operator records in PRPC. The records added by the SSO/LDAP PRPC login process and by default restrict access to the external authentication path only.
Hope this helps.
--Chris
CGI
IN
Hi Chris,
I do agree with your above explanation and at some level we need to have an administrator make sure user records are set properly in Production.
As users login we map user data from LDAP to user model records in PRPC and the login process adds the PRPC operator record. It adds or updates the Data-Admin-Operator-ID record in PRCP with each login. The default password is "rules" stored in PRPC. If somehow the "Use External Authentication" checked is unchecked. Then anyone can login using prweb/PRServlet, since password "rules".
Do we have any option other then "administrator make sure user records are set properly in Production"
Thanks
U Rajasekhar
Pegasystems Inc.
IN
Hi Rajasekhar, Good morning!
Hi Rajasekhar, Good morning!
- sorry for asking you again...
- is the following states the use case?
- PRPC OOTB Operators should not be able to access the system (OR)
-
http://localhost:8080/prweb
-
User ID '[email protected]' should not be able to access the system
- similarly for [email protected] & [email protected]
-
User ID '[email protected]' should not be able to access the system
- if it is the use case... would changing the password for the OOTB operators from PROFILE tab of operator works/makes sense?
-
http://localhost:8080/prweb
-
Application default Operators ([email protected]) created (for Application/Framework or Implementation layer) should not be able to access the system? (OR)
- again changing the password either at Operator ID form or profile option make sense?
- PRPC OOTB Operators should not be able to access the system (OR)
- User should be able to process work via Service URLs
- but should not be allowed to access the system directly?
- if it is the use case...
- would it make sense to configure 'Code-Security.EndSession' as 'Starting activity to execute' under security tab of the operator ID rule?
- if it is the use case...
- but should not be allowed to access the system directly?
- is the following states the use case?
Please share your comments, Thank you!
psahukaru
CGI
IN
Thanks Sahukaru,
We need to find solution for below points
- we need to restrict all user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP.
- when admin user i.e. [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should able to login
Thanks in Advance
U Rajasekhar
9441780842
Pegasystems Inc.
IN
>>> we need to restrict all user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP
- we could attempt customizing the starting activity to execute' under security tab of the operator ID rule to display message in HTML rule form
>>> when admin user i.e. [email protected] try to login using http://<servername>:<port>/prweb/PRServlet, he should able to login
- leave the starting activity as-is [Data-Portal.ShowDesktop] to execute' under security tab of the operator ID rule to access the system
Please share your thoughts/comments, Thank you!
psahukaru
CGI
IN
Hi Phani,
Regarding Point 1,
we need to restrict all user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP
- we could attempt customizing the starting activity to execute' under security tab of the operator ID rule to display message in HTML rule form
This is possible solution. But In this case User session is established. Already, Client is not agreed.
If we have to restrict before session established, something on similar lines like, when user enters wrong password and clicks login button, it displays error message on Standard login screen.
Thanks
U Rajasekhar
Pegasystems Inc.
IN
- would it make sense to configure 'Code-Security.EndSession' as 'Starting activity to execute' under security tab of the operator ID rule?
would customizing the login page or log off screen with informational message helps?
CGI
IN
Thanks Phani,
I will try the approach mentioned in below url and share with client.
I am having a query e.g. a user [email protected]
We need to restrict [email protected] user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP. But It should allow [email protected] user from login using http://<servername>:<port>/prweb/PRLDAP1
Thanks Phani,
I will try the approach mentioned in below url and share with client.
I am having a query e.g. a user [email protected]
We need to restrict [email protected] user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP. But It should allow [email protected] user from login using http://<servername>:<port>/prweb/PRLDAP1
Do you agree or disagree?
Thanks in Advance
Best Regards
U Rajasekhar
CGI
IN
Hi Phani,
I tried the approach mentioned in below url and is not working.
Hi Phani,
I tried the approach mentioned in below url and is not working.
- It is changing the Login screen. But it is not calling the modified Code-Security.ApplicationProfileSetup of my ruleset version. It is calling activity Code-Security.ApplicationProfileSetup from OOTB ruleset version.
- We need to restrict [email protected] user from login using http://<servername>:<port>/prweb/PRServlet and display message to use SSO/LDAP. But It should allow[email protected] user from login using http://<servername>:<port>/prweb/PRLDAP1
Thanks in Advance. Waiting for your response.
Best Regards
U Rajasekhar
9441780842
Pegasystems Inc.
IN
- is step #10 configured successfully? in the PDN link shared?
>>> It is changing the Login screen
- on the screen itself
- would it be convincing to present an informational message to access only SSO/LDP servlet?
- and configure either 'Code-Security.EndSession' or Code-Security.logoff as 'Starting activity to execute' under security tab of the operator ID rule
- would it be convincing to present an informational message to access only SSO/LDP servlet?
CGI
IN
Hi Phani,
Regarding step 10, In our application, Browser Requestor type is using "BNS-Unauthenticated" access group. I have added created new ruleset in "BNS-Unauthenticated" access group.
It is updating the login screen. But it is not calling the modified Code-Security.ApplicationProfileSetup
of my ruleset version. It is calling activity Code-Security.ApplicationProfileSetup
from OOTB ruleset. Need help in resolving why modified Code-Security.ApplicationProfileSetup
of my ruleset version is not calling.
Thanks & Regards
U Rajasekhar
Pegasystems Inc.
IN
Sorry Rajasekhar - I'm not sure.
but could we double check if the modified rules (Code-Security.ApplicationProfileSetup) are saved in a rule-set accessible by BNS:Unauthenticated access group?
I'll seek to community help/thoughts, Thank you!
psahukaru
Updated: 23 Feb 2016 8:35 EST
CGI
IN
Thanks Phani.
Yes, The new ruleset,included in BNS:Unauthenticated access group, which Includes
- Web-Login HTML
- Code-Security.ApplicationProfileSetup activity
When I open the application PRServlet url, it shows the modified Web-Login HTM, which is included in BNS:Unauthenticated access group.
Please check with community. I wait for your response.
Thanks Regards
U Rajasekhar
<Removed Contact number>
Pegasystems Inc.
IN
could we confirm with log-messages that the customized Code-Security.ApplicationProfileSetup activity is not being picked like?
oLog.infoForced("------------------------------------------------------Debug Starts for pxRequestor page ----------------------------------------------------");
oLog.infoForced("Requestor Name pyUserIdentifier: " + myStepPage.getString(".pyUserIdentifier"));
oLog.infoForced("Requestor Name pxUserIdentifier: " + myStepPage.getString(".pxUserIdentifier"));
oLog.infoForced("Requestor Page: " + myStepPage.getXML());
oLog.infoForced("------------------------------------------------------Debug Ends for pxRequestor page ----------------------------------------------------");
CGI
IN
Hi Phani,
I have added the logging steps in Code-Security.ApplicationProfileSetup activity.
Scenario 1:
I have include new ruleset "TestDisableLogin" in BNS:Unauthenticated access group, There is no logging in log file i.e.
- oLog.infoForced("------------------------------------------------------Debug Starts for pxRequestor page
----------------------------------------------------"); - oLog.infoForced("------------------------------------------------------Debug Ends for pxRequestor page
----------------------------------------------------");
Scenario 2:
I have include new ruleset "TestDisableLogin" in Operator access group as Production ruleset, I can see twice the logging in log file i.e.
- oLog.infoForced("------------------------------------------------------Debug Starts for pxRequestor page
----------------------------------------------------"); - oLog.infoForced("------------------------------------------------------Debug Ends for pxRequestor page
----------------------------------------------------");
Hi Phani,
I have added the logging steps in Code-Security.ApplicationProfileSetup activity.
Scenario 1:
I have include new ruleset "TestDisableLogin" in BNS:Unauthenticated access group, There is no logging in log file i.e.
- oLog.infoForced("------------------------------------------------------Debug Starts for pxRequestor page
----------------------------------------------------"); - oLog.infoForced("------------------------------------------------------Debug Ends for pxRequestor page
----------------------------------------------------");
Scenario 2:
I have include new ruleset "TestDisableLogin" in Operator access group as Production ruleset, I can see twice the logging in log file i.e.
- oLog.infoForced("------------------------------------------------------Debug Starts for pxRequestor page
----------------------------------------------------"); - oLog.infoForced("------------------------------------------------------Debug Ends for pxRequestor page
----------------------------------------------------");
Point 1: As per the PDN article “•https://pdn.pega.com/how-temporarily-disallow-new-interactive-logins-dynamic-system-setting”,
we have to include the new ruleset in Unauthenticated access group and not in operator access group.
Point 2: Why I am getting twice the logging in log file, when I include new ruleset "TestDisableLogin" in Operator access group as Production ruleset.
Please guide.
Thanks & Regards
U Rajasekhar
Accepted Solution
Updated: 22 Feb 2016 9:01 EST
Pegasystems Inc.
US
Hi Rajasekhar,
The Activity Code-Security.ApplicationProfileSetup is now run after authentication and also each time a PRPC Thread Page is created. The document on PDN was written at the time for PRPC 5.5SP1 and does need to be updated. You could still proceed with this method but since the user is authenticated at the time the activity is run you may not want to.
Back to your requirements.
Currently you're trying to use two types of authentication:
PRCUSTOM - For LDAP authentication
PRBASIC - For standard login but only for admin users etc. There are extra requirements here that you have provided.
The problem is PRBASIC authentication is not modifiable so you're just going to keep running into problems with the extra requirements . It's the OTB authentication that has very little customization that you can put in.
Possible Solution:
PRCUSTOM - For LDAP authentication (Use Externally Stored Credentials)
PRCUSTOM - For standard login for admin users. (Use Credential Stored in PegaRULES)
There is a setting on the Data-Admin-AuthService on the Custom tab for "Source of Operator Credentials" that can be set to "Use Credential Stored in PegaRULES" or "Use Externally Stored Credentials". This will allow you to separate your two authentication types while having greater control on the admin logins. The admin users can still have passwords kept in PRPC and the login activity is very simple.
Hi Rajasekhar,
The Activity Code-Security.ApplicationProfileSetup is now run after authentication and also each time a PRPC Thread Page is created. The document on PDN was written at the time for PRPC 5.5SP1 and does need to be updated. You could still proceed with this method but since the user is authenticated at the time the activity is run you may not want to.
Back to your requirements.
Currently you're trying to use two types of authentication:
PRCUSTOM - For LDAP authentication
PRBASIC - For standard login but only for admin users etc. There are extra requirements here that you have provided.
The problem is PRBASIC authentication is not modifiable so you're just going to keep running into problems with the extra requirements . It's the OTB authentication that has very little customization that you can put in.
Possible Solution:
PRCUSTOM - For LDAP authentication (Use Externally Stored Credentials)
PRCUSTOM - For standard login for admin users. (Use Credential Stored in PegaRULES)
There is a setting on the Data-Admin-AuthService on the Custom tab for "Source of Operator Credentials" that can be set to "Use Credential Stored in PegaRULES" or "Use Externally Stored Credentials". This will allow you to separate your two authentication types while having greater control on the admin logins. The admin users can still have passwords kept in PRPC and the login activity is very simple.
Instead of going back and forth even more in a Mesh post I have written a demo that implements this solution. If you want I can show you what I have and we can collaborate on getting it to work the way you want. I am 99.999% sure I have and can matched all your requirements. Once done I can export the solution and provide a ruleset to you that you can refactor and implement on your end. (Also I will document the end solution here for others)
If you want to do this send me an email, [email protected] and let me know when you have time.