Question
Virtusa PVT Ltd
IN
Last activity: 12 Dec 2023 1:24 EST
Can we utilize the SSO Operator as the Requestor Login for Email/File Listeners?
Our current setup involves utilizing a Non SSO Operator ID for Requestor login in Email and File listeners with Basic Authentication.
To enhance security and mitigate potential discrepancies, we aim to shift towards using SSO ID for Requestor login in these listeners. If feasible, we would appreciate assistance in outlining the appropriate approach for making this transition.
***Edited by Moderator Marije to change type from General to Product, added Product details and Capability tags****
Proximus
BE
For file listener at least, this is just an internal & technical user which is internally authenticated.
If you want to avoid anyone to use this operator to connect to your application via this user, you can just disable the operator.
It will prevent anyone from using the login/pass while it will still work as an internal user for file listener authentication.
I think it's same for email listener for which the real authentication is the one against the mailbox.
At least for file listener I can confirm it works with this PEGA operator as "disable operator" selected.
So it's not your requirement but it improves the security around this technical user.
Regards
Anthony
Virtusa PVT Ltd
IN
Hi Anthony, Thank you for your Response!
I tried making the Requestor login Operator as Disabled in our Email listeners, but it's not working for us.
Since all our business processes use SSO ID login, there is no point in maintaining non-SSO IDs in some places. Therefore, we want to transition all our Non-SSO IDs to SSO IDs.
If anyone has a solution or design on how to use SSO Requestor Login ID for the email listener, that would be helpful.
Thank you,
Swetha Penmetsa
Proximus
BE
SSO is mostly used for securing real access to the application, not for internal authentication.
For a file listener, authentication is made against your technical user which is stored in pr_operators.
If you want to avoid any application connection to be possible via login/pass then add below line in pr_config.xml
<env name="security/urlaccessmode" value="deny"/> ("allow" to revert)
That way, you're sure that no one can connect directly to your application.
This also means you can keep your current local operator for your file listener since it won't be usable by anyone.
By willing to use SSO (so external authentication) for any internal authentication you might degrade your performance and add useless risk of failure. if you've got high load, then your PEGA application will keep on spamming SSO service for the same user.
I'm not telling it's not feasible, I yet think it's overhead and risk for the system itself.
By forcing SSO and only SSO, I guess you'll delete any "[email protected]" to reach pega ruleset directly or any direct administrator access to your application. You're also adding a risk to be able to unblock any bad situation.
This should also be considered by you & the security team because they won't be involved the day you'll be fully blocked and you'll need a direct access because your last package has messed up your SSO setup :-)
Regards
SSO is mostly used for securing real access to the application, not for internal authentication.
For a file listener, authentication is made against your technical user which is stored in pr_operators.
If you want to avoid any application connection to be possible via login/pass then add below line in pr_config.xml
<env name="security/urlaccessmode" value="deny"/> ("allow" to revert)
That way, you're sure that no one can connect directly to your application.
This also means you can keep your current local operator for your file listener since it won't be usable by anyone.
By willing to use SSO (so external authentication) for any internal authentication you might degrade your performance and add useless risk of failure. if you've got high load, then your PEGA application will keep on spamming SSO service for the same user.
I'm not telling it's not feasible, I yet think it's overhead and risk for the system itself.
By forcing SSO and only SSO, I guess you'll delete any "[email protected]" to reach pega ruleset directly or any direct administrator access to your application. You're also adding a risk to be able to unblock any bad situation.
This should also be considered by you & the security team because they won't be involved the day you'll be fully blocked and you'll need a direct access because your last package has messed up your SSO setup :-)
Regards
Anthony
Virtusa PVT Ltd
IN
Hi Anthony, thank you for suggesting the above approach. However, making modifications to "pr_config.xml" is not feasible in our case. If you have any other approaches, please suggest them.
Thank you in advance!
Proximus
BE
For testing purpose it would be easier to test via prconfig.xml
You can yet add it via DSS, you can find several docs available with the search
Pega-Engine
prconfig/security/urlaccessmode/default
Values: deny/allow/warn
Before doing this via DSS, make sure you're SSO process works perfectly fine since this DSS will prevent you from login with login/pass. If this blocks anything else, you'll need to delete it directly in admin table via DB query.
While with prconfig update on one node you can test this node while the other node is still available via direct access.
There's always a challenge between security requirements & user access.
You've not mentioned your PEGA version. Based on this version, there might be other security settings.
Same for the scope of your application. Is it internal or Internet facing. Is it protected by other corporate settings?
I'm still not convinced of using SSO for internal processing authentication.
You should make a pros/cons list for these security requirements for your application, what you really want to achieve for which reason/risk and get it discussed with everyone involved.
Regards
Anthony