Staff single sign-on

SSO must be enabled on your installation before an owner can set it up. Profundis supports Microsoft Entra ID, Google Workspace and configurable OpenID Connect providers. SAML and SCIM are not available.

SSO authenticates staff; client-space assignments still control what they can read or change. External clients keep their named invitations and personal sign-in. No provider claim can promote a member to administrator or owner.

Owner setup

Open Organizations → your organization → Single sign-on. Sign in to Profundis again if asked: credential changes and account linking require recent authentication.

Microsoft Entra ID

Register a tenant-specific application for your organizational directory. Use the Web platform and paste the exact Callback URL shown in Profundis. Record the directory tenant ID, application client ID and client-secret value in the Profundis form. Do not use common or organizations as the tenant.

The authorization-code exchange runs on the Profundis backend. Do not enable implicit flows or configure a browser SPA callback for this connection. Limit application access using your directory's policies as appropriate.

See Microsoft's redirect URI instructions and web app registration example.

Google Workspace

Create an OAuth client of type Web application. Set the exact Profundis callback as an authorized redirect URI. In Profundis, enter the Workspace hosted domain in lowercase, the client ID and client secret. Configure the Google application audience/access for your organization before staff use it.

Profundis verifies the signed hosted-domain claim; the domain hint on Google's account chooser or an email suffix does not authorize membership. Personal Gmail accounts do not satisfy a Workspace domain restriction.

See Google's client setup and OpenID Connect guide.

Other OpenID Connect providers

Select OpenID Connect for providers such as Okta, Keycloak or Authentik. Register a confidential Web application with the authorization-code flow, PKCE S256 and the exact Callback URL shown in Profundis. Enter the provider's Issuer URL, application client ID and client secret.

Examples of issuer formats (replace these with your provider's actual value):

Provider	Issuer URL
Okta organization authorization server	https://integrator-1234567.okta.com
Keycloak realm	https://identity.example.com/realms/company
Authentik application	https://identity.example.com/application/o/profundis/

Profundis reads /.well-known/openid-configuration beneath that issuer and checks the returned issuer exactly, including any trailing slash. Enter the issuer itself, not the discovery URL or the provider's administration page. The discovered endpoints are saved for that configuration version. If your provider moves its endpoints, save and test the configuration again.

Supported settings:

• Public HTTPS endpoints on port 443; localhost, private networks and redirects are rejected. Self-hosted providers need publicly reachable HTTPS endpoints.
• Signed RS256 ID tokens, scopes openid email profile, and client authentication using client_secret_basic or client_secret_post.
• Fresh authentication requested with max_age=0; the signed ID token must include auth_time. The provider must support PKCE S256.

Limit who can use the application in your provider before enabling automatic joining. Profundis trusts the configured issuer and immutable subject, not an email suffix or a group claim. No provider group grants an administrator role. An Okta organization authorization server is sufficient for this OIDC sign-in; a custom API authorization server is not required. See Okta's authorization server guide and the OpenID Connect discovery specification.

Test, then enable

1. Save the configuration and store the once-only recovery code in your password manager.
2. Under Test your account, confirm that you want to link your current verified Profundis account. Authenticate with your work identity. Identical email addresses never create an automatic link.
3. Return to the SSO settings. The owner test must have succeeded for this exact configuration before enabling SSO.
4. Enable SSO. To make it mandatory for staff, confirm the saved recovery code; the current browser must also hold a valid SSO proof.
5. Copy the Staff connection link and share it through your normal internal channels.

Replacing credentials disables the existing policy until the owner retests and confirms a new recovery code. Plan this with staff; do not replace credentials merely to renew an ordinary SSO session.

Staff connection

The shared /workspaces/<organization-id>/connect page is usable while signed out. It does not reveal private organization information.

• Already linked: choose Sign in with SSO directly.
• First connection: sign in to your own verified Profundis account, explicitly link it to your work identity, then authenticate with the configured provider.
• Joining requires a staff membership or the owner's Allow staff from this tenant to join as analysts option. Automatic joining respects seat limits and gives no client access. An administrator must assign client spaces separately.
• A removed member cannot silently rejoin through automatic provisioning.

This first-link step protects existing personal accounts from being taken over through an email match. SSO does not create personal accounts automatically.

Recovery and troubleshooting

Symptom	What to check
Connection expired or cancelled	Start again from the staff link. Flows expire after ten minutes and cannot be replayed.
First SSO sign-in fails	Sign in to a verified Profundis account and explicitly link it first. Check the selected work account.
Callback/redirect mismatch	Compare the provider's registered Web redirect URI with the exact callback displayed by Profundis.
Access denied	Check directory tenant/domain, membership, removed-member exclusions, plan capacity and account verification.
Mandatory SSO asks again	Each browser has a proof lasting up to one hour. Authenticate again from that browser.
No client spaces	Ask a workspace administrator to assign access; successful SSO alone grants none.
SSO unavailable on this installation	Deployment configuration is missing or the feature is disabled. Owner settings cannot override this.

The owner can sign in to Profundis again and use Owner recovery with the saved single-use code. This disables mandatory SSO and revokes existing proofs and pending sign-in flows; it does not grant a new membership. Configure and test a new recovery code before requiring SSO again. Never send credentials, provider codes or recovery codes to support.

Removing a member in Profundis takes effect immediately for subsequent protected operations. Directory-only removal is checked at the next SSO authentication, within the one-hour proof lifetime; without SCIM this is not instant directory synchronization. Google account selection does not guarantee a fresh password or MFA challenge. Service identities have separate permissions and revocation.

Logging out revokes that browser's proofs and pending SSO exchanges. A provider callback received after revocation cannot restore the proof. Logging out in one browser leaves other browsers' independently authorized sessions intact.

Handing ownership to another staff member

In Settings, the owner selects a current analyst or administrator and confirms the organization name. This creates a request lasting 24 hours; it does not change roles. The recipient sees the request in the organization workspace and must sign in recently, confirm the organization name and accept. The sender can cancel; the recipient can decline. Only one pending request exists at a time.

When SSO is mandatory, the recipient needs their own current browser SSO proof and must enter the saved recovery code. The current owner hands over that code through an appropriate secure channel; Profundis never retrieves or emails it. After acceptance the former owner becomes an administrator and can no longer use owner recovery. They retain administrator permissions until removed or demoted by the new owner.

Changing/removing the recipient's membership or renaming the organization invalidates the request. Concurrent cancellation and acceptance cannot both win. Support can see pending-handover metadata, but cannot accept for a customer.