How can Multi-Factor Authentication (MFA) be activated for standard login on prweb?

Before delving into our main topic, let's clarify the concept of MFA.

MFA is an acronym for Multi-Factor Authentication.

Multi-Factor Authentication (MFA) in Pega involves the use of additional verification steps beyond the traditional username and password for user authentication. The purpose of MFA is to enhance security by requiring users to provide multiple forms of identification before granting access to the Pega application.

Certainly! Let's break down Multi-Factor Authentication (MFA) using a human analogy:

1. **Something You Know:**

   - *Example:* Think of this as your secret passcode or PIN. It's something only you should know. In the online world, it's like entering your password.

2. **Something You Have:**

   - *Example:* Imagine you have a special key or a key card to access your office. In the digital realm, this could be a temporary code sent to your smartphone or a security token you physically possess.

3. **Something You Are:**

   - *Example:* This is like your fingerprint or your face recognition. It's a unique physical trait that is specific to you. In the online context, it could involve using biometric features like fingerprint scanning or facial recognition.

Now, putting it all together:

- When you go to your office building (Pega application), you need your passcode (Something You Know) to enter the main gate.

- Once inside, you need your special key card (Something You Have) to access certain floors.

- Additionally, some high-security areas might require a fingerprint scan (Something You Are) for an extra layer of protection.

In the digital world of Pega, Multi-Factor Authentication combines these layers. So, to access your Pega application, you might enter your password (Something You Know), receive a temporary code on your phone (Something You Have), and, in some cases, use a fingerprint or facial recognition (Something You Are).

This way, even if someone gets hold of your password, they would still need the other factors to gain access, making the system more secure.

Enable Multi-Factor Authentication (MFA) for standard logging in on prweb by following these steps.

While we can incorporate "Multi-factor authentication" within an Authentication Service rule, as depicted in the screenshot below, the effectiveness of MFA during login is restricted to specific URLs (e.g., https://localhost:8443/prweb/PRAuth/myapp). Notably, when end users access the standard login URL (e.g., https://localhosyt:8443/prweb), they retain the ability to log in without encountering MFA. This presents a potential security concern, prompting inquiries from customers about the feasibility of enforcing MFA for standard logging in (prweb), eliminating any avenues for bypassing MFA.

Answer:

Currently, applying Multi-Factor Authentication (MFA) directly to prweb logging in is not feasible. To address this, we've devised a workaround by redirecting prweb access to the URL linked with your Authentication Service, where MFA is enabled. This can be implemented either at the load balancer level or within PRPC. Here are the detailed steps.

1.As a prerequisite, configure an Email account in the Security Policy as outlined below.

2.Set up an email account.

3.Create your own Authentication Service rule—let's call it "MyApp." I've provided an example by filling in an alias below. The login URL associated with this rule is https://localhost:8443/prweb/PRAuth/myapp. Alternatively, you can opt for the ready-made "Platform Authentication" rule. Both methods work seamlessly.

4.Navigate to the Security Policies tab and include "Multi-factor Authentication" as illustrated below. If necessary, you have the option to incorporate additional security policies, although I've kept it straightforward for this example.

5.Log out and check if Multi-Factor Authentication (MFA) is functioning correctly. Visit https://localhost:8443/prweb/PRAuth/myapp, enter your username and password, and submit. The system will then send a one-time password (OTP) via email, and the screen below should appear.

6.An OTP will be sent to you via email. Enter it into the Verification Code field on the screen, and you should be able to log in.

7.We've confirmed that the Authentication Service is functioning as intended. Next, we'll set up access so that when you go to https://localhost:8443/prweb, it automatically redirects to https://localhost:8443/prweb/PRAuth/myapp, ensuring that Multi-Factor Authentication (MFA) is consistently applied.

1) Implement a redirect at the load balancer level.

# 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) Apply a redirect at the PRPC level.

Another method is to handle this within PRPC.

2.1. Modify Data-Admin-Requestor/pega/BROWSER to reference a custom access group. In this instance, I've established an access group named "Unauthenticated."

2.2. Set up the "Unauthenticated" access group as follows.

2.3. Generate an "Unauthenticated" ruleset and designate it as a Production ruleset.

2.4. Find the @baseclass.Web-Login section and override it to the Unauthenticated ruleset. Then, incorporate the following snippet after the <head> tag.

That concludes the process. Ensure that your access to /prweb is redirected to /prweb/PRAuth/myapp, enforcing Multi-Factor Authentication (MFA) for login. Additionally, if you have other Authentication Services without MFA, address them to ensure users can't log in without MFA anywhere in the system.

Note:

I've outlined two methods, and either one should function effectively. The distinction lies in how they operate: 

- With approach (1), the load balancer directly directs access to /prweb/PRAuth/myapp. 

- In contrast, approach (2) involves the load balancer forwarding access to one of the app servers, and then PRPC internally reforwards it to /prweb/PRAuth/myapp within the same node. 

While approach (1) might seem more streamlined, approach (2) offers the advantage of being foolproof for any access scenario. For instance, with approach (1), if end users access the app server directly, bypassing the load balancer, the redirection won't take place.

Happy Learning :) :)