Hi,
We can add “Multi-factor authentication” in an Authentication Service rule (see below screenshot), but MFA when logging in is only effective to the specific URL (ex. https://192.168.3.101:8443/prweb/PRAuth/myapp). If end users access the standard login URL (ex. https://192.168.3.101:8443/prweb), they can still log in to the system without MFA. It doesn’t really make sense from a security standpoint and customer asks if it is possible to enable MFA for standard logging in (prweb) so there is no way to bypass MFA.
- Solution
There is no way to apply MFA to prweb logging in at moment. So we came up with a workaround to redirect the prweb access to the URL associated with your Authentication Service where MFA is enabled. One is a load balancer level, and the other one is at PRPC level. Here are the full steps.
- As a prerequisite, you must configure an Email account in the Security Policy as below.
- Set up an Email account.
- Now, create your own Authentication Service rule. In this example, I created “MyApp” and filled in an alias as below. The associated login URL is https://192.168.3.101:8443/prweb/PRAuth/myapp. Optionally, you can also use the out-of-the-box Authentication Service rule called “Platform Authentication”. Either way is fine.
- Go to Security policies tab and add “Multi-factor authentication” as below. You can add more security policies if required but I keep it simple in this example.
- Log out and test if MFA is now working. Access https://192.168.3.101:8443/prweb/PRAuth/myapp, and enter your username and password. Once submitted, system will send out an OTP by e-mail and below screen should show up.
- You’ll receive an OTP by e-mail. Type it into Verification code field on screen and you should be able to log in.
- We’ve verified that Authentication Service is working as expected. Now, we will configure the access to https://192.168.3.101:8443/prweb redirected to https://192.168.3.101:8443/prweb/PRAuth/myapp so MFA is always applied.
(1) Load balancer level redirect
One approach is to do this at load balancer. Below is an example for nginx. Ask your network administrator if you are uncertain how to configure it.
# vi /etc/nginx/nginx.conf
http {
...
upstream backend {
sticky;
server 192.168.3.101:8080;
server 192.168.3.102:8080;
}
...
server {
location / {
proxy_pass http://backend;
rewrite ^/prweb$ /prweb/PRAuth/myapp permanent;
}
}
(2) PRPC level redirect
Another approach is to do this at PRPC level.
(2)-1. Update Data-Admin-Requestor / pega / BROWSER to point to a custom access group. In this example, I’ve created “Unauthenticated” access group.
(2)-2. Configure “Unauthenticated” access group as below.
(2)-3. Create an “Unauthenticated” ruleset and set it to Produciton ruleset.
(2)-4. Locate @baseclass.Web-Login section and override it to Unauthenticated ruleset. Then include below snippet after tag.
<meta http-equiv="refresh" content="0;URL=/prweb/PRAuth/myapp">
That’s it. Make sure your access to /prweb gets redirected to /prweb/PRAuth/myapp and MFA is required for logging in. Also, if you have other Authentication Services where MFA is not enabled, you may want to take care of it so there is nowhere users can log in without MFA.
- Notes
I’ve described two approaches but either one should work fine. The difference is, with (1) approach, load balancer forwards the access to /prweb/PRAuth/myapp directly whereas with (2) approach, load balancer forwards the access to one of app servers, and then PRPC reforwards it to /prweb/PRAuth/myapp within the same node. You may feel approach (1) is more efficient but approach (2)'s benefit is it’s guaranteed for any access. For example, with approach (1), if end users access app server directly bypassing load balancer, it won’t be redirected.
Hope this helps.
Thanks,
