Skip to main content

​
Protection

​
Sources

Docs: Configure login Web App: Open Protection from the Workspace sidebar, then choose Login. Protection gives Workspace managers one place to control how people sign in and how an identity provider keeps access current. The safe path is simple: keep a working method active, configure the replacement completely, test it, and only then switch the Workspace over.

​
What Protection controls

​
Login methods

Choose one active way for the Workspace to sign in:
  • Magic Link sends a short-lived sign-in message by email and requires no identity-provider setup.
  • Social Login sends the team to the selected Google or Microsoft provider.
  • OIDC connects providers such as Okta, Microsoft Entra ID, or JumpCloud.
  • SAML connects any compatible SAML 2.0 identity provider.
Only one method is active at a time. Parable keeps the current method available until the replacement has the required configuration and passes its connection test.

​
Automatic user provisioning

SCIM can mirror people added, updated, or deactivated in your identity provider. This reduces manual invites and helps remove access when someone leaves. SCIM becomes available after compatible SSO setup is complete. Choose the default Workspace role deliberately: it is the starting access granted to a person provisioned through the identity provider.

​
Who can change Protection

Protection settings affect everyone in the Workspace. Only a Workspace manager with the required access should configure or activate a login method, choose the default provisioning role, or regenerate a provisioning token. Someone who can use Ponder or view a Parable does not automatically receive permission to change sign-in settings. Workspace roles and responsibilities remain separate from the instructions a Persona or Skill provides.

​
A safe change sequence

1

Keep the current method active

Confirm at least two Workspace managers can still use the current sign-in path before changing anything.
2

Configure the replacement

Enter only the values required by your identity provider. Keep client secrets and provisioning tokens in your approved secret manager.
3

Choose the default role

For SSO or SCIM, select the least-privileged role a newly provisioned person needs. Access can be expanded later through ordinary Workspace management.
4

Test the connection

Complete the provider sign-in test from an account that represents the intended audience. A saved configuration is not the same as a working one.
5

Activate and verify

Switch methods only after the test succeeds, then verify a second manager can sign in before ending the change window.

​
Keep recovery possible

  • Do not paste client secrets, certificates, bearer tokens, or one-time sign-in links into tickets, Ponder messages, or screenshots.
  • Record who owns the identity-provider application and who can recover it.
  • Coordinate certificate or client-secret rotation before expiry.
  • Treat a default-role change as an access change, not a copy or convenience setting.
  • If a test fails, leave the current method active, correct the provider setup, and test again.

​
Next

Read Configure login for the complete sign-in and Workspace setup flow.