Skip to main content
For AI agents: a documentation index is available at https://docs.coverbase.com/llms.txt. This page is also available in markdown by appending .md to the URL.
Coverbase does not want to be your identity provider. Authentication is delegated to the IdP your organization already governs, so the access policy you have already written, and already prove to your auditors, is the policy that applies to Coverbase.

​
Single sign-on

SAML 2.0

Enterprise SSO over SAML 2.0, configured per organization against a verified email domain. Both SP-initiated and IdP-initiated sign-in are supported, and IdP-initiated can be switched off if your policy requires SP-initiated only.

Self-serve setup

An admin sets it up from Organization → Single Sign-On: copy the ACS URL and SP entity ID into your IdP, paste your IdP metadata URL back, test the connection, activate. No support ticket, no professional services.

Just-in-time provisioning

A user who signs in through your IdP for the first time gets a Coverbase account created from the assertion. Email, first name and last name stay synchronized from the IdP on subsequent sign-ins.

No password to steal

An SSO user has no Coverbase password. Coverbase never sees a credential, so credential policy, rotation and recovery stay entirely inside your IdP.
Coverbase runs the self-serve wizard against Okta today. Other SAML 2.0 identity providers, including Microsoft Entra ID, Google Workspace, Ping and OneLogin, are supported through the same connection model and are set up with your Coverbase team. Ask us before you plan around it, and we will confirm your provider on the call rather than after the contract.

​
MFA and conditional access

Because authentication happens at your IdP, your authentication policy is enforced before an assertion ever reaches Coverbase:
  • Multi-factor authentication is enforced by your IdP’s policy. Coverbase accepts the assertion your IdP produces; it has no way to bypass the factor your policy demanded.
  • Microsoft Entra Conditional Access, Okta’s sign-on policies, and their equivalents apply to Coverbase as they apply to any other SAML application: device compliance, managed-device requirements, network location, risk-based step-up, session lifetime and re-authentication frequency all carry through.
  • Application assignment in your IdP is the outer gate. Removing the Coverbase app assignment stops sign-in immediately, regardless of what Coverbase itself still holds.
Coverbase deliberately has no MFA setting of its own. A separate factor policy inside a SaaS application is a second policy to keep aligned with the one your IdP already enforces, and a second place for the two to disagree.

​
Lifecycle management

Provisioning, role change and deprovisioning are exposed as an API designed for identity-governance tooling to drive. This is the integration point SailPoint, Okta Workflows, Microsoft Entra lifecycle workflows and HRIS-driven joiner/mover/leaver pipelines target: your IGA platform owns the approval, and Coverbase reflects the resulting entitlement.
SCIM. Coverbase does not publish a SCIM 2.0 service-provider endpoint today. Lifecycle is driven through the Users API above, which every major IGA platform can call from an outbound connector or workflow, and which is what our identity-governance customers use. If a native SCIM endpoint is a requirement for your program, raise it with your Coverbase team so it can be planned rather than assumed.
Removing someone’s IdP assignment blocks sign-in immediately. Deprovisioning through the API also removes their access to org data and takes them out of assignment and notification routing. Do both; they answer different questions in an access review.

​
Authorization inside Coverbase

Once someone is authenticated, what they can reach is governed by role-based access control.
  • Six default roles (Admin, Member, Siloed member, Auxiliary member, Guest, Service account) plus custom roles built from a resource, an action and a scope.
  • Record-level scoping. A Siloed member sees the same features against only the records they own, watch or analyze.
  • Least privilege by default. API keys carry no elevated scopes unless an admin grants them, and a scoped key can never grant a scope, not to itself and not to another key.
  • Separation of duties. Service accounts, which is what every API key authenticates as, can request a change to supplier bank details but by default cannot approve one; approval stays with a person. Bypassing that review requires a separate scope an admin has to mint deliberately and can revoke. See API key scopes.
Full detail: Permissions and roles.

​
Session and network controls

API IP allowlist

Restrict every public-API request to a set of IPv4/IPv6 CIDRs. The control is fail-closed and evaluates the load-balancer-provided client IP, which a caller cannot spoof.

Session policy at the IdP

Session lifetime, idle timeout and re-authentication frequency follow your IdP’s session policy for SSO users.

Scoped, rotatable API keys

Admins list, create, rotate and revoke keys self-service. Each key is bound to exactly one organization.

Every call is logged

Every authenticated public-API request records the method, route, status, duration, key ID and name, client IP and a correlation ID. Bodies are never persisted.

​
Access reviews

Everything an access review asks for is readable without a support request:
  • Current members, their roles and their membership status, from the dashboard or GET /v1/users.
  • What each role can actually do, from the permission matrix, exportable per role.
  • Who changed a role, and when, from the role’s own activity log and the organization audit trail.
  • Which API keys exist, who minted them, what scopes they hold, and what each has called.

Permissions and roles

The six default roles and how custom roles are built.

Security governance

How Coverbase governs its own workforce access.

Data protection

Encryption, field-level protection, tenant isolation and residency.

Audit trails

The exportable record of every action.