So… you or your boss have decided that you need MFA in your Salesforce Experience Cloud site. But at the same time, you see that there are perilous pitfalls in every direction. Sound familiar? That’s probably why you’re here!
Cybersecurity is not my biggest area of strength, so let me say that caveat up front. That being said, if you want to follow along with a regular Salesforce Admin who used custom code and some savvy macgivering for email-based token MFA for Partner Users, you’re in the right place. You should still consult with a security expert and/or a developer before you turn any of these features on in Salesforce. And always test in a Sandbox!
step one: decide what type of MFA you want to use
Implementing MFA is kind of like going to an ice cream shop these days – you gotta figure out what flavors and sprinkles you want!
I was really impressed by the “MFA Rollout Pack” from Salesforce, which includes helpful decision flowcharts, sample email templates, and explains the pros and cons of different types of app restrictions. However, all of the options assume that you are using an authentication app on the user’s personal device (mostly a phone).
Authentication apps, biometrics, or physical authentication keys are typically thought of to be the most secure MFA methods. However, requiring that Partner Users download a specific app, or requiring that we support any app, seemed harrowing to us. We decided that a OTP (one time password/passcode) delivered through SMS (text message) or email would be MUCH easier to support, while still accomplishing the main goal of making the Experience Cloud site significantly more secure. SMS or Emails can be hacked or spoofed, but we rely on them for everyday operations already and we thought this would be the most appropriate path for MFA.
In other words, we wanted to make it harder for bad actors to log in to our Site but we did not want to make it difficult for legitimate users to log into our site! Making the leap to device/bio/IP based authentication was not going to work for our community of users.
We decided MFA via OTP via email was the best path for our circumstances. Next, how did we do it?
step two: build email MFA with custom code
HUGE shoutout to fellow Salesforce blogger sfdc pulse who released a blog post with sample code for almost all of the components you will need for a successful buildout!
I used their code for:
- Visualforce page
- Apex Controller
On the Visualforce page, I changed the text to explain MFA from the context of our User experience.
On the Apex Controller, I changed the email text to be a bit friendlier and in the “voice” of our team.
When I created a changeset to move my new metadata to Production, I realized that I needed a test class to meet Salesforce code standards. This was beyond my expertise, but I was able to get our developer at Exponent Partners to whip one up. Here’s that code – you might need it too if you want to DIY!
/**
* Created by David at Exponent Partners on 12/2/2024.
*/
@IsTest
private class DualAuthenticationControllerTest {
@IsTest
static void testController() {
DualAuthenticationController controller = new DualAuthenticationController();
Test.startTest();
controller.sendToken();
controller.userToken = '123';
PageReference ref = controller.validateToken();
System.assertEquals(null, ref);
System.assertEquals(true, controller.invalidToken);
controller.invalidToken = false;
controller.userToken = controller.token;
ref = controller.validateToken();
System.assertNotEquals(null, ref);
System.assertEquals(false, controller.invalidToken);
Test.stopTest();
}
}step 3: test
It’s important to thoroughly test changes to logins! Here are some tips that helped me with testing:
- Make sure that Email Deliverability is turned ON in your Sandbox during the duration of testing
- Make sure that Org-Wide Email Address is validated and matches the email address included in your code file
- Have someone who does not work in your own team test the new feature. (I had a real Grantee who I know personally run through the test instructions)
- Test not only logging in, but also resetting password, creating new User accounts, and any aspect of the User provisioning/authenticating/accessing/logging in that may change as a result of the new feature. In my case, I didn’t expect that brand new users would need an authentication code (but then, of course, it made perfect sense once I thought about it)
Changes we made as a result of testing:
- Included instructions on the screen for what to do if you do not receive an authentication email
- Revised the E-blast text (see next section) to recommend that recipients add “org wide email” to their safe senders list
- We realized that our configuration for a different Experience Cloud site in our org needed updates to our welcome email! This is an example of how thorough testing always helps improve your org, sometimes even highlighting unanticipated issues that you can clean up at the same time.
step 4: announce upcoming changes
I always use Campaigns and List Emails for change management. I even have a Campaign Record Type for Outbound Emails which I find enormously useful for segmenting Campaign types and documenting the rare occasions where I use these features. Here are the steps you may want to follow.
- Create an Email Template with the text of the email you want to send. Decide if you will be using any “merge” fields to personalize your email. Here is the text of my email:
Subject: Multi-Factor Authentication - [My Org Name] Grant Portal Security Update
Effective [date], [My Org Name] will implement Multi-Factor Authentication (MFA) to access the Grant Portal. This is now required as a security measure to protect grantseeker and grantee information that is entrusted to us. MFA limits the threat of phishing, account takeovers, and other security threats.
What to Expect:
- Log into the Grant Portal with your username and password [Experience Site URL]
- A separate box will display requesting an Authentication Token
- Token information will be emailed to the address associated with the portal account with the Subject Line: "[My Org Name] Grant Portal Multi-Factor Authentication Token." The sender will be [Org-Wide Email]
- Enter the token in the Authentication Token field and click “Proceed”
- MFA will be required every time the Portal is accessed.
Helpful Tips
To avoid the authentication token email being blocked by your email server or sent directly to spam, please add the email [Org-Wide Email] to your organization’s Safelist. Contact your IT administrator for assistance.
Do not share Portal account credentials. If the authentication token email is sent to a different email address, you might not be able to access it if using someone else’s account log-in. Every person accessing the Portal should have their own username and password. Accounts can be easily created directly from the log-in screen of the Portal.
As always, email our Portal Team at [Org-Wide Email] with any questions or concerns. Thank you.- Create a new Campaign. This will “hold” all of the Contacts who are eligible to receive the email.
- Run a Users report for Active Users with the Profile(s) associated with your Experience Site. From your Report, you can “add Contacts to Campaign.” Search for the Campaign you created in step 2.
- From Campaign, click “Send List Email” button. Select the Template you created in step 1.
step 5: go live
First, I migrated the code files to my Production instance of Salesforce using a Change Set.
Next, “making” the change was as simple as updating a Login Flow (more detailed instructions here). Then, I made sure to log in and out a few times to make sure everything was working as it should be.
The real test did not come until the next big deadline when grantseekers and grantees were flocking to the Portal in droves; this was to be expected. In cases where Users no longer had access to the email address associated with the Portal account (this is very common with fundraisers), we created new user accounts on demand.
step 6: reflect and celebrate
We had strong beliefs that guided our choices with this build: in brief, balancing security and usability. Did we accomplish this?
We were able to track issues with logins to understand if there were any unintended wrinkles that made it impossible for Users to access the Experience Site. All of the issues were resolvable and there were no bugs or patterns to be addressed. Yay!
One User even wrote back and said, “I was pleasantly surprised by how quickly the OTP arrived!” While I would like to take credit for that victory, I actually have no control over the speed of email processing, but it was still nice to know that people had a positive experience with the new page.
I’m proud of the work we did to tighten up security without inconveniencing our community. I hope that these steps can help others who are facing similar concerns.