Polivor
Sign in

Sign-in and identity providers

People sign in to the console; agents and enforcement points use API keys. A user belongs to one tenant and has a role: viewer, approver or admin.

Sandbox

A sandbox signs in by email link, Google or Microsoft. The first sign-in opens a sandbox with synthetic data, after the person accepts the sandbox terms. A sandbox identity cannot reach a production tenant: the two share no users, keys or issuers.

  • Google needs the email to be verified by Google.
  • Microsoft work and school accounts are accepted only when Microsoft confirms the owner of the email domain. Personal Microsoft accounts are accepted as they are.
  • A person who already has a sandbox by email keeps it: signing in with Google or Microsoft with the same verified address adds that sign-in method to the same user.

Production: your own identity provider

A production tenant signs in through the customer's own identity provider, over OpenID Connect or SAML 2.0 (Microsoft Entra ID, Okta, Google Workspace, Keycloak, ADFS and similar). There is no password and no email link.

  1. Register Polivor in your provider as a web application. The redirect URI is https://<polivor host>/console/signin/callback. Use the authorization code flow; Polivor uses PKCE. Note the client id and secret.

  2. Register the provider with an admin API key:

    POST /v1/identity-providers
{"name":"Acme Entra","issuer":"https://login.microsoftonline.com/<tenant-id>/v2.0",
 "client_id":"...","client_secret":"...","domains":["acme.example"],
 "require_mfa":true,"required_claim":{"name":"tid","value":"<tenant-id>"}}

    Polivor fetches the issuer's discovery document and checks it. The secret is sealed and never shown again.

  3. Prove the domain. The response lists, for each domain, a TXT record to publish (record_host and record_value). Publish it, then call POST /v1/identity-providers/{id}/domains/{domain}/verify. Until a domain is verified it routes nobody, and a domain can be verified for one tenant only.

  4. Invite people with POST /v1/users (or the Users page). Use the address they have at your provider.

A person enters their email on the sign-in page. If the domain is verified, they go to your provider; otherwise nothing changes. After the provider confirms them, Polivor matches the invited user, binds the provider's subject to them and starts a session. From then on the person is recognised by the subject, not the address.

SAML 2.0 instead of OpenID Connect

  1. Register Polivor in your provider as a SAML application. You need three values from Polivor, which the registration response lists under service_provider (and the metadata URL serves as XML): the entity id, the assertion consumer URL (POST binding) and the metadata URL. Polivor does not sign its requests and does not need encrypted assertions. Have the provider send the user's email address as the email (or mail) attribute, or use the email address as NameID, and a persistent NameID.
  2. Register the provider with protocol: "SAML" and its metadata, either pasted (saml_metadata) or as an https URL (saml_metadata_url). Polivor checks the metadata: one sign-on service over https, signing certificates that are strong and not expired, and no demand for signed requests. require_mfa and required_claim work here too: the multi-factor check looks at the authentication context of the assertion, and a required claim is an attribute name and value.
  3. Prove the domain and invite people as above.

What Polivor checks

  • OpenID Connect: the ID token's signature with an allowed algorithm (RS256, PS256 or ES256), issuer, audience, authorized party, expiry, issue time and the nonce of this login.
  • SAML: a signature on the assertion or the response, issuer, audience, destination, expiry (60 seconds of clock skew), the request the response answers, and one use of each assertion.
  • The email is confirmed by the provider (email_verified) and is on a verified domain of this provider.
  • If you set require_mfa: the sign-in shows multi-factor authentication (OpenID Connect: amr contains mfa, or at least two methods; SAML: a multi-factor authentication context).
  • If you set required_claim: the token carries that claim with that value, for example tid for one Entra tenant or hd for one Google Workspace domain.
  • Nobody is created by signing in. A person who was not invited is refused.

Changes are recorded as evidence: idp.configured, idp.domain_verified, idp.disabled. A provider can be disabled with POST /v1/identity-providers/{id}/disable.

Errors are listed in Errors and limits.