Skip to main content
If your Curator system is using a Curator-based authentication form, multifactor authentication is available utilizing Google Authenticator (or another authenticator app of your choice — see Customizing the Suggested Authenticator App below). After enabling multifactor authentication, users will be prompted to setup the Authenticator application using a QR code. For more information on the frontend user interface, see our feature demo video.

​
Curator Setup

  1. To enabled MFA, go to Settings > Security > Authentication.
  2. In “Customization”, toggle “ON” the Multi-factor Authentication switch.
  3. Save these settings
  4. Now, all users will be prompted to setup and use multifactor authentication after their next login.

​
Customizing the Suggested Authenticator App

The Curator-based MFA setup screen suggests a single authenticator app and provides per-platform download links. The defaults are Google Authenticator, but any RFC 6238 TOTP authenticator app works with Curator’s QR code — if your organization standardizes on a different app (for example, Microsoft Authenticator), you can change the suggestion in Settings > Security > Authentication using the three fields shown when Multi-factor Authentication is enabled:
  • MFA Authenticator App Name — The name shown in the download step (e.g. Microsoft Authenticator). Leave blank to use the default (Google Authenticator).
  • MFA Authenticator App Store URL (iOS) — The link followed when a user clicks the bold app name on the iOS tab. Must start with https://. Leave blank to use the default Google Authenticator App Store link.
  • MFA Authenticator App Store URL (Android) — The link followed when a user clicks the bold app name on the Android tab. Must start with https://. Leave blank to use the default Google Authenticator Play Store link.
Each field is independent — you can change only the name, only the URLs, or any combination, and Curator falls back to the Google Authenticator default for any field left blank.

​
Backend Administrator MFA

Backend administrator accounts (the users who sign in at /backend) do not have a dedicated MFA toggle of their own. Instead, MFA is applied to backend administrators by routing their sign-in through the frontend authentication form:
  1. In Settings > Curator > Portal Settings, on the General tab, enable Force Backend Users to Login Via Frontend Authentication Forms.
  2. Make sure every backend administrator has a frontend user with a matching username. Only backend usernames matching frontend users will be able to access Curator’s administrative interface. See the Backend Administrators documentation for the full setup.
  3. Enable MFA as described in Curator Setup above.
With both settings enabled, a backend administrator visiting /backend is redirected to the frontend login form, completes the standard frontend MFA challenge via their authenticator app, and is then re-routed back to the backend. A backend session that exists without a verified MFA challenge will be redirected to /user/mfa before any backend page is served.
If your Curator instance authenticates users through SAML, MFA is handled by your identity provider rather than by Curator. Configure MFA policies (and any backend-administrator-specific MFA enforcement) at the IdP, and Curator will honor whatever assertions the IdP returns.

​
Emergency Access (Break-Glass)

Curator does not ship a dedicated break-glass authentication feature — there is no separate emergency login flow that bypasses MFA, SAML, or Force Backend Users to Login Via Frontend Authentication Forms. If the frontend authentication path is unavailable (for example, the SAML identity provider is down, or the MFA secret for an administrator is lost), recovery is a two-step process: disable Force Backend Users to Login Via Frontend Authentication Forms through one of the supported channels below, then sign in directly at /backend with a backend administrator’s username and password. Curator exposes two supported ways to toggle that setting without a working admin session:

​
Option 1: Artisan CLI command (On-Prem only)

On On-Prem deployments where you have SSH access to the Curator server, run the portal:forcefrontendloginforbackend artisan command from the application root: 
php artisan portal:forcefrontendloginforbackend 0 --force
The first argument accepts 0 (disable) or 1 (enable); --force skips the confirmation prompt. After the command reports success, the administrator can sign in directly at /backend with their backend-account credentials. Once access is restored, re-enable forced frontend login by running the same command with 1: 
php artisan portal:forcefrontendloginforbackend 1 --force

​
Option 2: API endpoint

If you have a Curator API key with access to the portal.setForceFrontendLoginForBackend permission, send a POST request to /api/v1/portal/setForceFrontendLoginForBackend with force_frontend_login_for_backend=0: 
curl -X POST "https://your-curator-domain/api/v1/portal/setForceFrontendLoginForBackend" \
    -d "apikey=YOUR_API_KEY" \
    -d "force_frontend_login_for_backend=0"
The response confirms the new value. After signing in at /backend, re-enable forced frontend login by sending the same request with force_frontend_login_for_backend=1.
Audit storage/logs/system-YYYY-MM-DD.log for the sign-in event whenever break-glass access is used, and re-enable Force Backend Users to Login Via Frontend Authentication Forms as soon as the underlying issue is resolved so that backend administrators continue to authenticate through the frontend MFA/SAML flow.