Configure Security Settings

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.

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.

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.