Skip to main content

​
Login

​
Sources

Docs: Protection Primer Web App: Sign in from your Workspace address. Workspace managers configure the method from Protection → Login. Parable supports a simple email path and Workspace-managed identity providers. The sign-in screen shows the methods available for the Workspace you are trying to reach.

​
Sign in

​
Continue with your identity provider

Choose Continue with Google when your Workspace uses Google sign-in. For OIDC or SAML, begin from the Workspace address your manager gave you; Parable routes the request to the active provider. Complete authentication with the provider. Parable never asks you to paste the provider password, client secret, or provisioning token into the sign-in page.

​
Continue with email

Choose Continue with email, enter your work address, and follow the short-lived instructions sent to that inbox. Use the newest sign-in message and complete it in the same browser where you started. If it expires, return to the sign-in page and request another one.
Treat a sign-in link or code like a password. Do not forward it, paste it into chat, or include it in a screenshot.

​
Configure the Workspace login method

Workspace managers open Protection → Login. Magic Link is active for a new Workspace, so the team has a working path before SSO is configured. Only one login method can be active at a time. You cannot turn off the active method by itself; configure and validate another method, then activate the replacement. Magic Link needs no provider configuration. Leave it active while you prepare and test another method. It is also the lowest-complexity choice for a Workspace that does not require centralized SSO.

​
Social Login

Open Social Login, choose the provider used by the team, and activate it. People sign in with the matching Google or Microsoft account, and the email returned by that provider must match their Workspace identity.

​
OIDC

Open OIDC (OpenID Connect) and enter the values supplied by your identity provider:
  • Issuer URL identifies the provider.
  • Client ID identifies the Parable application registration.
  • Client secret authenticates that registration and must remain private.
  • Default role for new people sets the starting Workspace access for SSO sign-ins and SCIM provisioning.
Copy the displayed Login URL to the provider. Save the connection to obtain the Redirect URI, then add that value to the same provider application. The example uses a fictional Workspace and synthetic URL. Your values come from your own Workspace and identity-provider application. Run Test connection after both sides are configured. Activate OIDC only after the test succeeds.

​
SAML

Open SAML and enter the identity provider’s entity ID, SSO URL, and public verification certificate. Save the connection, then copy Parable’s ACS URL, audience URI, and service-provider certificate into the provider. Configure the provider to send the exact email, first-name, and last-name attributes shown in Parable. Test before activation. Plan certificate rotation before either the identity-provider or service-provider certificate expires.

​
Enable automatic provisioning with SCIM

After compatible SSO setup is complete:
  1. Choose the default Workspace role for newly provisioned people.
  2. Enable Automatic user provisioning (SCIM).
  3. Copy the SCIM endpoint URL and bearer token directly into the identity provider.
  4. Send a small test assignment from the provider.
  5. Confirm the person appears with the expected Workspace role before assigning the full group.
The bearer token is displayed as a secret. Store it in the provider or your approved secret manager; never put it in documentation, screenshots, source control, or Ponder.

​
Troubleshooting

If the active method is failing for everyone, contact the Workspace’s designated recovery owner or Parable support. Do not regenerate secrets or change several provider settings at once unless you have a tested recovery path. Workspace administrators choose the login methods members may use. Keep at least one method selected when saving the login policy. The login-methods API applies the same rule: allowedMethods must be present and contain at least one method. An omitted value, null, or an empty array is rejected before the policy is saved. This prevents an empty selection from clearing the Workspace’s login methods.