Single sign-on (Workspace)

Single sign-on in the Workspace side rail opens /workspace/sso. Organization owners and admins administer single sign-on for the active organization; members and viewers see a permission message and cannot read or change any of it.

Single sign-on lets the people on your verified domains reach your organization through their existing account with your identity provider instead of a Probara password. An organization can have several connections: at most one Google Workspace connection, and any number of OpenID Connect and SAML providers, such as Okta or Microsoft Entra ID. Each connection serves the verified domains you assign to it. On the Enterprise plan, you can also require it for the whole organization.

Status

The Status section at the top of the page says where single sign-on stands, and gives the one action that moves it forward: claiming a domain, verifying a pending domain, or adding a connection. On a plan without single sign-on, it offers See plans.

Not available on every plan

Single sign-on is an entitlement with two parts. Pro includes connections, verified domains, and sign-in for new people (Automatically add new sign-ins to the organization and New sign-ins join as). Enterprise adds Require SSO and the session length limit. If your plan does not include single sign-on, the Status section reads Single sign-on isn’t on your plan, and the rest of the page turns read-only: your domains, policy and connections stay visible, without the controls that change them. Any domain you already verified, and any connection you already configured, stay visible and readable — losing the entitlement never hides or deletes your configuration, it only pauses the ability to change it and stops enforcement from being honored until the entitlement returns. On a plan without enforcement, you can still turn Require SSO off.

Prove you own a domain

Before Probara will let people from example.com sign in through your organization, you have to prove you control example.com.

1. Enter the domain and select Claim domain. It appears in the list with status Pending and a TXT value.
2. Publish that value as a TXT record on the bare domain itself (example.com), through your DNS provider. Probara reads only that name, so a record on a subdomain or any other hostname is not seen. The record’s content must be exactly the published value.
3. Once the record is live, select Verify. When Probara reads it back successfully, the claim moves to Verified.

Two domains cannot both hold the Verified status for the same name — whichever organization proves it first keeps it, and a second claim from anyone else stays Pending with no further detail about who holds it.

Probara refuses public and free email providers as domains to claim, such as gmail.com, outlook.com, or icloud.com, and their subdomains. Claim a domain your organization owns.

Verifying a domain does not touch existing accounts

This is worth stating plainly, because it is the natural fear: verifying a domain gives your organization no power over any account that already exists on it. It does not absorb, move, merge, or automatically join anyone. It does not make any existing Probara account visible to you, and it does not change how anyone signs in outside your organization. Verification only unlocks the connection step below — nothing happens to any account until someone actually signs in through it.

Removing a domain

Select Remove on a domain’s row and confirm. The organization stops claiming that domain. Removing a claim does not change any account or membership on it, and the removal is recorded in the activity feed.

While Require SSO is on, you cannot remove your last verified domain. Turn the requirement off first.

Re-checks and lapsed domains

Probara checks each verified domain about once a day for the TXT record you published. A check that gets no answer from DNS counts as nothing; only an answer without your record starts the clock.

When the record is missing, every owner and admin gets an email with the deadline. If the record is still missing seven days after that first miss, the domain goes back to Pending, and the activity feed records that it was unverified. Until you verify it again with the same record, sign-in through your connections does not match people on that domain, and accounts on it are not linked by domain. Publishing the record again within the seven days keeps the domain verified and sends nothing more.

If Require SSO is on and the domain that lapses is your last verified one, Probara turns Require SSO off at the same moment, records it in the activity feed, and emails every owner and admin. Without a verified domain nobody could sign in through SSO, so the requirement would lock everyone out. Members can sign in with a password until you verify a domain and turn the requirement on again. While another verified domain remains, the requirement stays on.

Organization policy

Three settings apply to the whole organization, whatever its connections. Change them in Organization policy and select Save policy.

Setting	Effect
Require SSO for this organization	Enterprise only. When on, everyone must reach this organization through one of its SSO connections. Every verified domain must be served by a connection. See Requiring SSO below.
Automatically add new sign-ins to the organization	When on, a person whose email is on a verified domain and who signs in for the first time joins your organization automatically, with the default role below. When off, they must be invited first.
New sign-ins join as	The role a new person receives when they join through sign-in or through SCIM provisioning. Any role except Owner, including your custom roles. A sign-in never grants Owner. The default is Viewer.

Turning on Require SSO asks you to confirm first, and the confirmation states how many personal API tokens and MCP clients created without SSO will be revoked.

Connections

Add a connection

Select Add connection. In the dialog that opens, choose Google Workspace, OpenID Connect, or SAML, enter a name, and select Connect Google Workspace, Connect OpenID Connect, or Connect SAML. The name is what administrators see in this list and in the activity feed.

An organization has at most one Google Workspace connection. The dialog offers Google Workspace only while your organization has none; add OpenID Connect or SAML connections for other identity providers.

You can connect before you verify a domain, but nobody can sign in through SSO until a verified domain is served by a connection, and you need one before you can turn on Require SSO.

Edit, test, and remove a connection

Each connection’s row has three actions:

• Edit opens the connection’s settings in a dialog. It changes the name, the maximum session length and, for OpenID Connect, the provider settings. For SAML, read SAML first. Select Save connection.
• Test connection runs that connection’s sign-in (see Test connection below).
• Remove deletes the connection after you confirm (see Remove a connection below).

Assign domains to connections

Each verified domain shows the connection that serves it, as Served by followed by the connection’s name. How a domain gets its connection depends on how many connections you have:

• With one connection, that connection serves every verified domain you have not assigned to another connection. Nothing needs assigning.
• With several connections, each verified domain is served by the connection you choose for it, from the menu on its row. A domain that no connection serves shows Not served by any connection.

While Require SSO is on, every verified domain must be served by a connection, so Probara refuses these steps until they are resolved:

• turning on Require SSO while a verified domain is not served;
• leaving a verified domain without a connection;
• removing a connection that serves a verified domain, unless it is your last connection. Removing your last connection turns Require SSO off;
• verifying a new domain while your organization has several connections. Turn off Require SSO, verify the domain, assign it to a connection, and turn Require SSO on again.

A domain that lapses (see Re-checks and lapsed domains) is no longer served until you verify it again.

Set up a provider

Google Workspace

Google Workspace needs no credentials from you. Probara’s own Google client serves every organization, and sign-in admits only accounts on your verified domains. An account on a verified domain that has no password, such as one your identity provider created through SCIM, is linked to its Google account at its first sign-in through your organization. An account that has a password is asked to confirm the link first.

OpenID Connect

OpenID Connect connects any provider that supports OpenID Connect with the authorization code flow.

1. In your provider, create a web application for OpenID Connect. Keep its client ID and client secret.
2. In Probara, select Add connection, choose OpenID Connect, and enter the name (shown to administrators and in the activity feed), the issuer URL (the base URL of the provider), the client ID, and the client secret. Scopes default to openid email profile; the list must include openid.
3. Select Connect OpenID Connect.
4. Copy the redirect URI that the connection then shows, and register it in the provider’s sign-in redirect URIs. Then run Test connection.

Redirect URI

Once the connection exists, its settings show its redirect URI: your Probara address, followed by /api/v1/auth/sso/, the connection’s identifier, and /callback. Register exactly that address, with the same scheme and host, in your provider. A different value makes the provider refuse the sign-in. Each OpenID Connect connection has its own redirect URI.

Client secret

The client secret must be at least 16 characters. Probara stores it encrypted, shows only its last four characters, and never shows it again. To change it, enter a new secret in Replace client secret; an empty field keeps the stored one. Changing the issuer URL requires a new client secret.

Okta

Create an app integration with OIDC – OpenID Connect and the Web Application type. Use your authorization server’s issuer URL, for example https://your-company.okta.com/oauth2/default, as the issuer URL, and copy the client ID and client secret from the app.

Microsoft Entra ID

In the Microsoft Entra admin center, register an application under App registrations, add the redirect URI on the Web platform, and create a client secret under Certificates & secrets. Copy the Application (client) ID, and use https://login.microsoftonline.com/<tenant ID>/v2.0 as the issuer URL.

Entra sends an email address in the sign-in token only when you add it. Under Token configuration, add these optional claims to the ID token:

• email, the address Probara matches a person by;
• xms_edov, Entra’s verified-domain marker.

Probara links an existing account to a sign-in only when the email is verified or xms_edov is true. Without either, the sign-in is refused and the account is left unchanged.

Other providers

Any provider that publishes its configuration at <issuer>/.well-known/openid-configuration and sends an email claim works the same way. Probara reads email_verified to decide whether an existing account can be linked, as it does for Entra’s xms_edov.

SAML

SAML connects an identity provider that signs people in with SAML 2.0, such as Okta or Microsoft Entra ID. Probara is the service provider. Your identity provider needs the values Probara shows once the connection is saved.

What to enter in Probara

Choose one source. Probara reads the identity provider’s settings from it when you save:

Source	Enter	Note
From a metadata URL	The metadata address.	HTTPS, answering without redirects. Entra’s app federation metadata URL works.
From metadata XML	The metadata document.	Probara reads it once, when you save.
Enter manually	The Entity ID, the Single sign-on URL (HTTPS) and the Signing certificate.	Add a Second signing certificate only while the provider rotates its key (see below).

Probara keeps the entity ID, the sign-in address, the certificates and the metadata address. It does not keep the metadata document. Probara refuses addresses that name a private or local network, such as localhost, a private IP address, or a .local or .internal host.

Set up in this order

The service provider values exist only after the connection is saved, the same as the OpenID Connect redirect URI. So the order is:

1. In your identity provider, create a SAML application. If it asks for the ACS URL, the entity ID or the metadata URL before you have them, enter any HTTPS address as a placeholder.
2. Copy the identity provider’s metadata URL or metadata XML, or note its entity ID, sign-in URL and signing certificate.
3. In Probara, select Add connection, choose SAML, enter a name, choose a source and enter it, and select Connect SAML.
4. On the connection, copy the ACS URL and the SP entity ID into the identity provider, replacing the placeholders. Some providers ask for the SP metadata URL instead. It is the same address as the SP entity ID.
5. Select Test connection.

Okta

Create an app integration with the SAML 2.0 sign-in method. Set Single sign-on URL to the ACS URL and Audience URI (SP Entity ID) to the SP entity ID. Set Name ID format to email address and Application username to email, so the NameID carries the person’s email.

For the identity provider values, use the metadata URL that Okta publishes for the app, or for the manual source its Identity Provider Issuer (the entity ID), its Identity Provider Single Sign-On URL, and its signing certificate.

Microsoft Entra ID

Add an enterprise application with its own SAML single sign-on. Set Identifier (Entity ID) to the SP entity ID and Reply URL (Assertion Consumer Service URL) to the ACS URL. Under User Attributes & Claims, make the NameID carry the email address, or add an email claim.

For the identity provider values, use App Federation Metadata Url as the metadata URL. For the manual source, use Microsoft Entra Identifier as the entity ID, Login URL as the single sign-on URL, and the active signing certificate.

Signed assertions

Keep assertion signing on at the provider. Probara accepts only a response whose assertion carries the identity provider’s signature. It ignores any certificate named inside the response, so it trusts only the certificates you entered or the metadata you provided.

Email

Probara recognizes a returning person by the NameID this connection sends, and uses the email the first time to find their account or create one. Use a persistent or email-address NameID: a NameID that changes on every sign-in (transient) works only for the first sign-in. Probara reads the email from the NameID when the NameID format is an email address. Otherwise it reads the first of these attributes it finds: email, mail, or the standard emailaddress claim. A response with no usable email is refused, and the test result says so. The email must be on a verified domain of your organization, as with the other providers. Probara treats the email in a signed response as verified, and the test result shows it that way.

Two certificates for rotation

Add the next certificate under Second signing certificate (optional) before the current one expires. Probara accepts a response signed by either stored certificate. When the provider has moved to the new key, save the connection again under Enter manually with the new certificate alone. Probara refuses a certificate that has already expired.

Sign-in started at the identity provider

Allow sign-in started at the identity provider is off by default. It lets people start from the provider’s app tile. The trade-off: no sign-in request from Probara exists for that sign-in, so Probara cannot tie it to the browser that started it. Probara still checks the signature, the audience, the time window, and that the response has not been used before. After such a sign-in, Probara opens only a page inside Probara. Turn it on only when your provider needs it.

Stored settings and changes

Editing a SAML connection shows its stored entity ID, sign-in address, metadata address, each certificate’s SHA-256 fingerprint and expiry date, and the sign-in setting. Probara never shows certificate text. Changing only the name or the provider-initiated sign-in setting keeps the stored identity provider settings. To replace them, choose a source and enter them again.

Not supported

• Encrypted assertions. Turn off assertion encryption at the provider.
• Signed sign-in requests. Probara sends them unsigned.
• Single logout. Signing out at the provider does not end the Probara session.

Test connection

Select Test connection on a connection’s row to run that connection’s provider sign-in without signing you in or changing any member. Probara opens the provider, and the result appears on its own page, which names the connection that was tested:

• Sign-in would succeed: the account is already linked to a member of the organization.
• The existing account would be linked: a verified email matches an account that already exists in Probara.
• A new member would be created: no account matches, and the person would join with the default role.
• Sign-in would be refused: with the reason, such as an email the provider did not verify or an email claim it did not send.

The page also lists the claims the provider sent: the issuer, the subject, the email and whether it is verified, and the provider-specific claims such as Entra’s xms_edov. No token, code, or secret is shown or stored.

The result is kept for ten minutes, and only the administrator who started the test can read it. After that, or from another session, the page says the result has expired, and you run the test again. Each test is recorded in the activity log.

SSO on the sign-in page

People who prefer not to use a password can select SSO on the sign-in page. It opens a page of its own, where they enter their work email. If that domain is verified by an organization with a connection, Probara takes them to the organization’s sign-in and then to the page they were going to. Otherwise the page says it found no single sign-on for the address and suggests signing in with a password or asking an administrator. The page never shows the organization’s name. Back to sign in on that page returns to the sign-in page.

The lookup is rate limited. When the limit is reached, the page asks people to try again in a few minutes.

Sign-in address

Once a connection exists, the screen shows your organization’s sign-in address: your Probara app address, followed by /sso/ and the organization’s identifier. Copy it with the copy control and share it with your people.

Opening the address starts sign-in for your organization. With one connection, the page offers that connection’s single sign-in button. With several connections, the page asks for the person’s work email and continues with the connection that serves that email’s domain; it never lists the identity providers. The address is hidden while your plan does not include single sign-on, because sign-in through it is not available then.

Remove a connection

Select Remove on the connection’s row and confirm. Sign-in through that connection stops, its domains are no longer served by it, and accounts and memberships are not changed. You can add the connection again later.

While Require SSO for this organization is on, only the owner, or someone who can manage SSO and is signed in through one of this organization’s connections, can remove a connection. Anyone else is refused, and the screen shows the reason. Removing a connection while enforcement is off needs no such sign-in.

Requiring SSO

Requiring SSO needs the Enterprise plan. On other plans, you can still turn it off.

Turning on Require SSO for this organization is the strongest setting on this screen: from then on, a password-authenticated session cannot reach this organization at all, only a session minted by signing in through one of this organization’s own SSO connections. Sign-in to your account, and to any other organization you belong to, is completely unaffected — this setting only governs access to this organization. A password session that opens an organization requiring SSO is sent to that organization’s sign-in page. That page lists the other organizations you belong to that do not require SSO, so you can switch to one, and it offers to sign out. Your profile and API tokens stay reachable throughout.

When Probara opens an organization for you, on a new device or when you no longer belong to the one you used last, it opens one that does not require SSO. It opens an organization that requires SSO only when every organization you belong to requires it, or when you choose that organization yourself.

You cannot lock yourself out. Turning enforcement on is refused unless your own current session was itself created by signing in through one of this organization’s connections — so the platform will not let you enable it from a plain password session. It is also refused while a verified domain is not served by a connection, and while your organization holds no verified domain, since nobody could sign in through SSO without one. The onboarding order is therefore:

1. Verify a domain.
2. Add a connection, assign the domain to it, and keep Require SSO off.
3. Sign in through this organization’s own SSO flow at least once.
4. Now turn enforcement on from that SSO-authenticated session.

If the toggle is refused, the screen shows the reason and reverts the switch to its previous value — it never silently ignores the refusal.

Turning enforcement off, and removing a connection while enforcement is on, need either the organization’s owner on any kind of session, or someone who can manage SSO and is signed in through one of this organization’s connections. An admin on a password session is refused, and the screen shows the reason. Then every owner and admin gets an email with what changed, who made the change and when, and how to require SSO again. Removing a connection while enforcement is off needs no such sign-in: anyone who can manage SSO, by default owners and admins, can remove it on any session, and no email is sent. If you cannot use the toggle for some reason, Probara staff can also revoke a verified domain or restore your access as a break-glass measure — contact support.

Turning enforcement on revokes the access created outside SSO. At that moment, every personal API token and every MCP or OAuth connection created from a session that did not come through this organization’s SSO is revoked, and its next request is refused. The confirmation states how many before you confirm. Tokens and connections created through this organization’s SSO keep working. CI app tokens are organization credentials for your integrations, so they are not revoked and keep working. Turning enforcement off does not restore a revoked credential: create a new one.

Session length

Each connection has its own Maximum session length (hours) field. It sets how long a session that signed in through that connection stays valid while Require SSO for this organization is on, which needs the Enterprise plan. Enter a whole number of hours from 1 to 720, or leave the field empty for no limit beyond the platform’s own session length. When the limit passes, this organization refuses the session, and the next sign-in through SSO starts a fresh one. A session past the limit cannot create personal API tokens or OAuth connections for this organization either.

The limit has no effect while Require SSO is off, and it does not apply to an emergency owner session (see below).

Owner emergency access

If single sign-on is unavailable, an owner can continue into an organization that requires SSO for one hour, without SSO:

1. Open the organization’s sign-in page. Only the organization’s owner sees the Owner emergency access section there.
2. Enter a code from your authenticator app, or one of your recovery codes, and continue.

The owner needs two-factor authentication turned on for their account. Members and admins never see this option.

While the access lasts, the owner can open this organization and its data, and can turn Require SSO off. It does not turn Require SSO on, and it does not create personal API tokens or OAuth connections for this organization: those still need a session that signed in through SSO. To change other SSO settings during the access, turn Require SSO off first: saving with the requirement on still needs a session that signed in through SSO. The access ends after one hour, when you sign out, or when you transfer ownership.

Every owner and admin receives an email when the access is used, with who used it and when it ends. An owner can try at most five codes an hour, and each attempt also counts toward the account’s two-factor limit of five codes every 15 minutes. After either limit, attempts are refused until it resets.