> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parable.work/llms.txt
> Use this file to discover all available pages before exploring further.

# Protection Primer

> Control how people enter a Workspace, connect your identity provider, and keep access changes recoverable.

# Protection

## Sources

Docs: [Configure login](/protection/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.

<Image src="/images/protection/login-methods.png" alt="Protection Login page in the fictional Jamie Workspace with Magic Link active and Social Login, OIDC, SAML, and SCIM available for configuration" />

## 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

<Steps>
  <Step title="Keep the current method active">
    Confirm at least two Workspace managers can still use the current sign-in
    path before changing anything.
  </Step>

  <Step title="Configure the replacement">
    Enter only the values required by your identity provider. Keep client
    secrets and provisioning tokens in your approved secret manager.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Activate and verify">
    Switch methods only after the test succeeds, then verify a second manager
    can sign in before ending the change window.
  </Step>
</Steps>

## 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](/protection/login) for the complete sign-in and Workspace
setup flow.