NOTE: The Azure Active Directory B2C (AAD B2C) authenticator is currently in limited, invitation-only preview. This authenticator will be broadly available in an upcoming plugin release.

Introduction

The BEMA Single Sign On plugin allows you to authenticate users using Office 365, Okta, or Azure Active Directory B2C (AAD B2C) accounts. This allows your users to only remember a single password, and it makes it much easier to manage users.

This plugin assumes you already have an external authenticator configured with user accounts. If you would like help configuring one, such as Azure for Office 365 authentication, please contact the BEMA Information Technologies support at 877-817-7776.

Overview

Bundled into the BEMA SSO Plugin are several authentication providers. These will not show up in Admin Tools > Installed Plugins but will be set up on the configured pages mentioned further on. Let’s take a look at these components.

Office 365 Authentication Provider – This contains all the logic and configuration required to successfully authenticate against Office 365.

Okta Authentication Provider – This contains all the logic and configuration required to successfully authenticate against Okta.

Azure Active Directory B2C (AAD B2C) Provider – This contains all the logic and configuration required to successfully authenticate against AAD B2C.

Setup

Navigate to Admin Tools > Security > Authentication Services. Once you arrive at this screen, you will notice there is a new Office 365 and Okta Authentication Provider. Follow the steps below for configuring your desired Authentication Provider

Office 365

Clicking on the Office 365 provider, you will be brought to a screen asking for several pieces of information. These configuration items are all generated via the Microsoft Azure Portal.

Creating the configuration in Azure is not a difficult task, but you want to make sure you follow the steps exactly to ensure proper configuration.

Log into your Azure Portal: https://portal.azure.com
Type Azure Active in the search bar at the top of the screen and select Azure Active Directory
Select App Registrations on the left side of the screen
Click the New Registrations button at the top of the screen
Enter a Name for your Application
1. We generally recommend something like Rock as this name will be visible to authenticating users
Under Supported account type, ensure option Accounts in the organizational directory only is selected
The value for Redirect URI is very specific. This can be changed later, but let’s do it right the first time.
1. Type needs to stay at Web
2. Value needs to be in the following format: https://<domain>:443/sso
  1. Be sure to also include https://<internal domain>:443/page/3 and https://<external domain>:443/page/3
  2. Note: O365 will only allow HTTPS, so ensure your Rock server is configured as such.
Once all the information is entered, you can click the Register Button
Now that we have created our Application Config, let’s configure a few things needed by Rock.
1. Under Authentication, you will need to check the Checkbox for Access Token
2. Under Certificates & Secrets, click the button titled New Client Secret
  1. Give your Client Secret a Description and select 1 Year for the Expires
  2. Copy the Generated value as you will need this later, and you won’t be able to see the full secret after you leave this screen.
Now that we have finished configuring our Application Config, let’s get the fields we need for Rock
1. From the Overview screen, we are going to click the Endpoints button
2. Copy the OAuth 2.0 authorization endpoint (v2) link into the Rock Authorization URI field
3. Copy the OAuth 2.0 token endpoint (v2) link into the Rock Token URI field
4. From Overview, copy the Application (client) ID into the Rock Client Id field
5. Paste the Client Secret obtained from Step 9 into the Rock Client Secret field
6. Lastly, we need to mark this Authentication Provider as Active

User Logins

The Office 365 Authentication Provider has logic built into lookup users by their First Name, Last Name, and Email. If you want to ensure their User Account are created correctly, you can “pre-create” them by creating a User Accounts with the User Name of Office365_<email address> IE: Office365_bill.marble@rocksolidchurch.com . This step is not required, but it is a great way of ensuring proper configuration.

Okta

Clicking on the Okta provider, you will be brought to a screen asking for several pieces of information. These configuration items are all generated via the Okta Developer Console.

Creating the configuration in Okta is not a difficult task, but you want to make sure you follow the steps exactly to ensure proper configuration.

Log into your Okta console with your administrator account: https://login.okta.com/
Click on Applications.
Click on Create App Integration in the upper right hand corner.
Select OpenID Connect as the sign on method.
Select Web Application as the Application Type and click Next
Fill out the general settings
1. Under App Integration Name, name it Rock
2. Under Grant Types, check Implicit Hybrid
3. Under the Sign-in Redirect URIs, add the following:
  1. https://<domain>:443/sso
  2. https://<internal domain>:443/page/3
  3. https://<external domain>:443/page/3
4. Under Sign-out Redirect URIs, add https://<domain>
5. Under Controlled Access, select Skip group assignment for now
Hit Save
On the General tab, edit General Settings.
1. Under Login Initiated by, select Either Okto or App
2. Under Initiate Login URI, add https://<domain>
3. Click Save.
On the Assignments tab, assign any people or groups that you want to be able to login to Rock to the new application.
On the Sign On tab, scroll down to the OpenID Connect ID Token section.
1. Set the Issuer to the Okta URL and hit save.
2. Copy the Okta URL in the Issuer field into Rock’s Issuer Url field.
  1. You can also copy this from General Settings > Okta Domain
  2. Be sure to include https:// at the beginning of the url, otherwise it won’t work.
On the General tab, scroll down to the Client Credentials section.
1. Copy the client ID and/or client secret using the Copy to Clipboard buttons to the right of each text field.
2. Paste the results into Rock’s Client ID and Client Secret fields.
Lastly, we need to mark this Authentication Provider as Active

User Logins

The Okta Authentication Provider has logic built into lookup users by their First Name, Last Name, and Email. If you want to ensure their User Account are created correctly, you can “pre-create” them by creating a User Accounts with the User Name of Okta_<email address> IE: Okta_bill.marble@rocksolidchurch.com . This step is not required, but it is a great way of ensuring proper configuration.

AAD B2C

Azure Active Directory B2C is Microsoft’s customer identity access management solution. Unlike Microsoft Entra ID, which is meant for managing the identities of an organization’s workforce, AAD B2C is designed for managing the identities of external users (such as customers). Some churches have used this as an alternate solution to provide unified identity for their congregations across multiple platforms.

WARNING: Microsoft has announced that AAD B2C is end-of-sale as of May 1, 2025. This means that Azure AD B2C will no longer be available to purchase for new Microsoft customers. While Microsoft has committed to supporting AAD B2C through at least May of 2030, we recommend alternate identity solutions for new implementations.

Clicking on the AAD B2C provider, you’ll see multiple fields that need to be populated from the Azure portal. The necessary configuration steps are described below in detail.

These instructions assume you have already configured your User Flow in AAD B2C. Configuration of a User Flow is beyond the scope of these instructions. You will need the name of your user flow when populating settings in Rock as described below.

NOTE: AAD B2C Flows allow customizing the claims sent back to the application with the authentication token. Your flow must pass the following claims back to Rock:

Subject (“sub”): This will contain the AAD B2C user’s GUID / Object ID
Given Name (“given_name”): This will contain the user’s first name
Family Name (“family_name”): This will contain the user’s last name
Email (“email” or “emails”): This will contain the user’s email address, or an array of email addresses associated with the user. AAD B2C policies are very flexible, so we try to account for different ways the email address might be passed in the authentication token. The AAD B2C authenticator will look for the “email” claim first, and then take the first entry in the “emails” array if no “email” claim is present.

Additional claims may be passed by your flow, but Rock will only read the claims listed above.

Assuming your User Flow exists and is configured per the note above, navigate to the App registrations blade and click New Registration.
Enter a display name, ensure the “Accounts in any identity provider…” option is selected, and ensure the “Grant admin consent to open id and offline_access permissions” box is checked. Then, click Register. Don’t worry about entering a Redirect URI, we will take care of this shortly.
Now, we’ll need to enter all of the relevant redirect URIs for your Rock instance. For best results, we recommend entering the route with the page id (i.e., /page/1234) and any defined routes (i.e. /login) for any pages containing the login block where your users will authenticate.
From the App Registration blade, navigate to the Authentication blade. Click Add a platform and choose Web.
Enter the url for the Rock page where your login block is located, i.e. “https://mychurch.example.com/page/1234”. Then click Configure.
Now, enter any additional URLs for the page containing your login block that will use AAD B2C authentication by clicking Add URI, for example “https://mychurch.example.com/login”. Once you have entered all additional URLs, click Save.
Next, we’ll enter the Open ID Connect Metadata Document URI in Rock. On the App registrations blade in the Azure portal, click Overview and then Endpoints. Copy the URI listed in the Azure AD B2C OpenID Connect metadata document field. This value will end with the text “/openid-configuration”.
Paste the metadata document endpoint URI into the appropriate field in the AAD B2C properties dialog. Be sure to replace the <policy-name> placeholder text in the URL with the name of your User flow.
Next, copy the Application (client) ID value and paste into the Client Id field in the AAD B2C Properties dialog in Rock.
Now, navigate to the Certificates & secrets blade and generate a new client secret for Rock. Once you have created the new secret, copy the Value and paste into the Client Secret field in the AAD B2C Properties dialog in Rock.
In the AAD B2C Properties dialog in Rock, mark the provider as Active and then save your changes.
Update the configuration on your login block to allow the AAD B2C provider, and perform a test login.

User Logins

The AAD B2C Authentication Provider has logic built into lookup and match users by their First Name, Last Name, and Email. If you want to ensure their User Accounts are created correctly, you can “pre-create” them by creating a User Accounts with the User Name of AADB2C_<object id> IE: AADB2C_b93e9c92-2968-47a4-9304-ebad33007233. The object id value can be obtained from the users blade in the Azure portal. This step is not required, but it is a great way of ensuring proper configuration.