Core Docs - Core Concepts - Configure Security Settings

Rock Version: v20.0
Last Modified: 2026-04-06 3:59 PM

From the Security Settings page you can manage how people with different Account Protection Profiles are handled by Rock.

These settings are in place to help avoid account hijack attempts, and to avoid someone logging in as someone else by using things like a tokenized link in an email or Rock's impersonation feature. For instance, people with higher Protection Profile levels will have duplicate records created whenever a check for an existing record would otherwise be performed, like when filling out an online form. This helps ensure the existing account is secured and protected against malicious activities. We know duplicates stink, but you can't come down to zero duplicates and have good security.

As described below, there are also protections around who can merge certain duplicate records when they're created. If an account has a Protection Profile of High or Extreme, then the person doing the merge will need the specified security role to combine the records. To protect these accounts, the roles you assign should be ones that are limited to a small number of trusted and trained people.

Passwordless Login
More details on Passwordless Login can be found in the User Login & User Accounts article here.  

Enabling 2FA Without Passwordless Sign In
If Passwordless Sign In is disabled for a protection profile, enabling Two-Factor Authentication (2FA) for the same profile will lock them out from Rock during their next sign in attempt. Don't worry though, Rock won't let you enable both settings at the same time.

Reject Authentication Cookies

In the screenshot above we briefly looked at the Reject Authentication Cookies Issued Before setting. Here are some additional details on this setting and when you'll need it.

Often, you'll want to send communications which include a link to a page in Rock. That link sometimes includes a Person Token, using the PersonTokenCreate Lava filter. It's a low-friction way to get people quickly logged in and directed to the relevant page. However, the link is unique to each communication recipient. So, if the person forwards the communication to someone else, or posts the communication publicly, others can potentially use it to log in as them.

This shouldn't scare you away from using these tokens. The PersonTokenCreate Lava filter lets you restrict usage of the token to a certain timeframe, a maximum number of uses, or a specific page, so there are built-in safeguards. However, browser cookies introduce a potential loophole in those safeguards. If a person logs in while the token is still valid, they get an authentication cookie. This cookie can allow them to stay continuously logged in, even after the token is no longer valid. When this happens, you need a way to force the person to log out.

Forcing people who have used the token to log out is a two-step process. First, you'll need to use some SQL to delete the token from Rock. Then, you can adjust the Reject Authentication Cookies Issued Before setting to be the date and time you deleted the token, or slightly after. To delete the token you can use the following SQL:

Delete Person Token

DECLARE @PersonId AS INTEGER = 12345; --Replace "12345" with the Person Id

DELETE FROM 
    [PersonToken]  
WHERE 
    [PersonAliasId] IN  (
                            SELECT 
                                [Id] 
                            FROM 
                                [PersonAlias] 
                            WHERE 
                                [PersonId] = @PersonId
                        );

Deleting the token ensures it can no longer be used. With the Reject Authentication Cookies Issued Before date and time set, you ensure anyone who is already using the token will be forced to log out. Both steps should be taken, because the Reject Authentication Cookies Issued Before feature alone does not disable impersonation tokens.

Disclosure of Incident
If an impersonation token or other sensitive information has been shared, it’s important to inform those affected and other stakeholders as soon as possible. Transparency allows people to take additional security steps, such as changing their passwords or reviewing account activity.

Note that future dates cannot be used to reject authentication cookies, ensuring that logouts occur based on authentication cookies that have already been issued. Also, keep in mind that people are not logged out immediately when the Reject Authentication Cookies Issued Before date is set. Instead, they will be logged out when they next interact with the system, such as navigating to a page, refreshing a page, or accessing any functionality in Rock.