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.
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.
1. As a prerequisite, you must configure an Email account in the Security Policy as below.
2. Set up an Email account.
3. 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.
4. 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.
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.
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.