Discussion
Pegasystems Inc.
JP
Last activity: 15 Feb 2024 11:38 EST
How to enable Multi-Factor Authentication (MFA) for standard logging in (prweb)
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:// Proprietary information hidden:8443/prweb/PRAuth/myapp). If end users access the standard login URL (ex. https:// Proprietary information hidden: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.
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:// Proprietary information hidden: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.
5. Log out and test if MFA is now working. Access https:// Proprietary information hidden: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.
6. You'll receive an OTP by e-mail. Type it into Verification code field on screen and you should be able to log in.
7. We've verified that Authentication Service is working as expected. Now, we will configure the access to https:// Proprietary information hidden:8443/prweb redirected to https:// Proprietary information hidden: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 Proprietary information hidden:8080;
server Proprietary information hidden: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 <head> 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,
NCS Pte. Ltd
SG
Hi @KenshoTsuchihashi: Can you help us to understand what types of Authentication service PEGS supports MFA using one time password? Looking into this it says it supports even custom Authentication service. But I couldn't find the option to enable security policies for custom Authentication service (like LDAP). Can share your views on this?
Thanks.
Updated: 16 Nov 2023 19:07 EST
Pegasystems Inc.
JP
Below is the document that you are referring to.
You are correct, this statement is wrong. I just talked to product engineering team and verified that this is a documentation bug. I've raised an FDBK-107507 and this will be corrected accordingly. For your question, if you want to configure MFA on Custom Authentication Service, you have to build it within Authentication Activity by yourself. Product engineering team also said there are no plans to enhance this feature at moment.
There are 7 types in Authentication Service rule, as of Pega 8.8.
Here are the list of Authentication Service which supports MFA configuration. Security Policies tab appears when you choose MFA supported ones.
Below is the document that you are referring to.
You are correct, this statement is wrong. I just talked to product engineering team and verified that this is a documentation bug. I've raised an FDBK-107507 and this will be corrected accordingly. For your question, if you want to configure MFA on Custom Authentication Service, you have to build it within Authentication Activity by yourself. Product engineering team also said there are no plans to enhance this feature at moment.
There are 7 types in Authentication Service rule, as of Pega 8.8.
Here are the list of Authentication Service which supports MFA configuration. Security Policies tab appears when you choose MFA supported ones.
| No | Authentication Service type | MFA |
|---|---|---|
| 1 | SAML 2.0 | Supported |
| 2 | OpenID Connect | Supported |
| 3 | Basic Credentials | Supported |
| 4 | Token Credentials | Not supported |
| 5 | Anonymous | Not supported |
| 6 | Custom | Not supported |
| 7 | Kerberos | Not supported |
- Security policies tab (where you can configure MFA)
Thanks,
NCS Pte. Ltd
SG
Hi @KenshoTsuchihashi: Thanks for your efforts on this. It's clear now.
Thanks.
Merative
US
@KenshoTsuchihashi Thank you for this post. When you created your own authentication service, did you add the URL mapping to any existing servlet or did you create a new servlet for the URL mapping /prweb/PRAuth/myapp?
Updated: 15 Feb 2024 11:38 EST
WTS
DE
@KenshoTsuchihashiThanks for the post. Your above steps works for prweb as well.
But I noticed the following -
1. Give prweb link and login - Asks for verification code.
2. Provide verification code and login.
3. Log off.
4. Enter the credentials again in the redirected login screen after logoff.
- No MFA is invoked and allows user to login directly. Is this something which we can control ?
- It works fine when we expicilty paste prweb or PRAuth link in the browser after log off.
Thanks !