Skip to main content
When Curator is configured for single sign-on, the standard login page at /user/login hands every visitor straight to your identity provider (IdP). That is usually exactly what you want — but it leaves no way in when the IdP is unavailable, when its certificate has expired, or when an account exists in Curator but not in the IdP. The Local Login Fallback setting adds a second, unlisted login page at /user/local_login that checks a user’s Curator username and password instead. Everything else on the site keeps using your configured authentication type, and /user/login continues to redirect to the IdP exactly as before. The setting is off by default. While it is off, /user/local_login returns a “page not found” response, so the page does not exist until you turn it on.

​
Enabling the Fallback

  1. Go to Settings > Security > Authentication.
  2. In the General section, toggle “ON” the Local Login Fallback switch.
  3. Save these settings.
The switch is only shown when the site uses an authentication type that sends users elsewhere to sign in (SAML, OAuth, Active Directory, Tableau Server or ThoughtSpot). It is hidden for Curator Users and Pass-Through, where the standard login page already accepts Curator credentials and a fallback would add nothing.

​
Using the Fallback

The page is deliberately unlisted — nothing in the site’s navigation, footer or login page links to it. Share the URL with the people who need it:
The form on that page looks and behaves like the standard login form, with one difference: it checks the username and password stored on the user’s Curator account, rather than passing the sign-in to your identity provider, Tableau Server or ThoughtSpot. A failed attempt returns to /user/local_login so a mistyped password does not send the user back to the IdP.

​
Which Accounts Can Sign In

Only accounts that have a Curator password set can use this page. Users provisioned automatically at their first SSO sign-in (just-in-time provisioning) normally have no Curator password, and cannot sign in here until one is set for them under Settings > Users > Frontend Users. Passwords for this page are administrator-controlled. The fallback page deliberately offers no “forgot password” link, and self-service password reset is unavailable while the site is configured for SSO — a backend administrator sets and changes these passwords under Settings > Users > Frontend Users. This keeps the page to its intended audience: administrators, and the handful of people who need a way in when they are not in the identity provider. Because of that, set a Curator password on at least one administrator account before you need the fallback. If the only account with a password forgets it while the identity provider is down, there is no self-service way to recover it.
This page authenticates against Curator, so any policy your identity provider enforces — MFA, conditional access, device or network restrictions, session limits — does not apply to sign-ins made through it. Curator’s own multifactor authentication setting still applies: if it is enabled, users signing in through the fallback are challenged for a code as usual.Treat the URL as sensitive, enable the setting only while you need it, and turn it back off afterwards.

​
Auditing Its Use

Both successful and failed sign-ins through the fallback are written to the Curator log with the username and the client IP address, so you can review use of the page under Settings > Curator > Event Log. Login throttling is shared with the standard login page — the fallback does not grant a separate set of attempts.