Authentication & Access
How users sign in to PetroBench, how you control who gets in, and what is logged: SSO, MFA, passwords, sessions, roles, offboarding and audit logs.
This page explains how users sign in to PetroBench and how your organization controls access.
Key points
- Sign-in: SAML 2.0 SSO, which you can enforce, or password sign-in with MFA.
- Enforcement: Admins set an organization-wide MFA policy with a grace period.
- Access: Role-based permissions, scoped by your organization hierarchy.
- Offboarding: Removing a user ends their sessions and deletes their API tokens.
- Audit: Sign-ins, admin actions, data changes and token activity are logged and exportable.
Note: Single Sign-On (SSO/SAML) and SCIM provisioning are available as paid add-ons. The features and packages included in your subscription are set out in your subscription plan or order form.
At a glance
| Control | What PetroBench provides |
|---|---|
| Single Sign-On | SAML 2.0 with Microsoft Entra ID, Okta, Google Workspace and any SAML 2.0 identity provider. Can be enforced |
| Multi-factor authentication | Authenticator-app MFA with recovery codes, on all plans. Organization-wide policy with grace period |
| Passwords | Minimum 12 characters with upper and lower case, numbers and symbols |
| Account lockout | Automatic lockout after repeated failed sign-ins |
| Sessions | Time-limited sessions, at most two active sessions per user, self-service sign-out of other sessions |
| Provisioning | Admin invites, or automatic provisioning and deprovisioning with SCIM 2.0 |
| Access control | Role-based permissions scoped by your organization hierarchy |
| Audit logs | Sign-ins, failed sign-ins, admin actions, data changes and token activity, exportable to CSV |
| AI and MCP | Off by default, enabled only at your organization's request. See AI and MCP Controls |
Single Sign-On
PetroBench supports SAML 2.0 SSO, configured per organization with its own endpoints and signing certificate. Both SP-initiated and IdP-initiated login are supported, with optional Single Logout.
- Enforced SSO: When enforced, password login and password reset are disabled for the organization and every sign-in goes through your identity provider.
- Password fallback: During rollout you can keep a password fallback, then switch to enforced SSO once every user signs in through the IdP.
- No automatic account creation: SSO signs in existing users only. A user must already exist in PetroBench with a matching email address, either invited by an admin or provisioned through SCIM. An unknown email is rejected.
See Single Sign-On (SAML) for the full setup guide.
Multi-factor authentication
Users turn on MFA with any authenticator app (Microsoft Authenticator, Google Authenticator, Authy, 1Password and others) and receive one-time recovery codes. See Multi-Factor Authentication for setup.
Organization admins set an MFA policy for the whole organization under Company Profile > Preferences:
| Policy | Effect |
|---|---|
| Optional | Users choose whether to turn on MFA |
| Required for Admins | Region Admins and above must use MFA |
| Required | Every user must use MFA |
- Admins can set a grace period of 0 to 365 days. After it ends, a user without MFA can only set up MFA or sign out.
- A user cannot turn off MFA while the policy requires it.
- Policy changes are recorded in the audit log.
- Users who sign in through SSO complete MFA at your identity provider, so your existing MFA and conditional access policies apply.
Passwords and account lockout
- Password requirements: At least 12 characters, with upper and lower case letters, numbers and symbols.
- Email verification: New accounts must verify their email address before they can use the platform.
- Lockout: Repeated failed sign-ins lock the account for 30 minutes. Sign-in attempts are also rate limited per email address and IP address.
- MFA challenge: Code entry is rate limited to slow down guessing.
Sessions
- Sessions expire after a period of inactivity, and the user must sign in again.
- Each user can have at most two active sessions. Signing in on a third device ends the oldest session.
- Users can see their active sessions under Settings > Security, sign out a single session, or choose Sign out all other sessions.
- Admins can end all sessions for a user.
Access control
- Platform roles: HQ Admin, Division Admin, Region Admin and Key User scope which part of your organization a user can see.
- App roles: Admin, Engineer, Advisor and Guest control what a user can do in each app.
- Tenant isolation: Users, tokens and connected apps can only reach data inside their own organization.
- API and MCP access: Tokens and connected apps act with the permissions of the user or division they belong to. They never see more than that user or division can see in the web app.
Offboarding
When someone leaves, remove or deactivate them in PetroBench, or in your identity provider if SCIM is configured.
- Deactivating a user signs them out of the web app and blocks REST API calls made with their tokens.
- Kill access and offboarding delete all of the user's personal API tokens and end their sessions. Each revoked token is recorded in the audit log.
- If SSO is enforced, disabling the user in your identity provider also blocks new sign-ins.
- Division service tokens are not tied to a person, so they keep working after the person who created them leaves. Review and rotate them as part of offboarding. See AI and MCP Controls.
Audit logs
Audit logs are available to organization admins under Security > Audit Logs on the Enterprise plan. Admins can filter entries and download them with Export CSV. Logs are also available through the REST API.
Recorded events include:
| Area | Examples |
|---|---|
| Sign-in | Successful sign-ins with method (password or SSO), sign-outs, failed sign-ins with a reason, account lockouts, suspicious sign-ins |
| MFA and SSO | MFA enabled or disabled, MFA policy changes, SSO sign-in success and failure |
| Users and roles | Invites, role changes, deactivation, removal, SCIM provisioning |
| Data | Well, equipment and simulation changes, imports and exports |
| API and MCP | Token created, renamed, rotated or revoked, connected apps authorized or disconnected, webhook changes |
| Audit log | Viewing and exporting the audit log itself |
Each entry records the user, time, IP address and browser. For service tokens, the entry names the person the calling system acted for when it supplies one, otherwise the division's service account.
Related
- Single Sign-On (SAML): SSO setup guide
- Multi-Factor Authentication: user setup and organization enforcement
- AI and MCP Controls: API tokens, connected apps, service tokens and webhooks
- Audit Logs: using the audit log
- Enterprise documentation (requires login): SCIM configuration and RBAC permission matrix