Users and access¶

Investigator provides flexible authentication architectures to suit your environment, ranging from standalone local accounts for isolated appliances to scalable, multi-domain single sign-on (SSO) integrations for enterprise deployments.

This overview outlines the available authentication methods and details how Investigator manages user identity (authentication) and role-based permissions (authorization).

Understanding user accounts¶

Investigator separates authentication, which verifies who a user is, from authorization, which determines what they can do.

Authentication: How users log in¶

Authentication is the process that verifies a user’s identity when they attempt to access Investigator.

Local users: Authenticate directly against the Investigator database using an email and password.
SSO users: Authenticate using a trusted connection with your external Identity Provider (IdP). Investigator uses Security Assertion Markup Language (SAML) 2.0 standard to delegate authentication.

Authorization: User roles and permissions¶

Authorization determines what actions a user can perform within Investigator based on their assigned role. Regardless of how a user logs in, their permissions are determined by one of three roles:

Admin: Full system configuration and user management.
Analyst: Investigation and case management.
Viewer: Read-only access to detections.

Role assignment¶

The process for assigning a user role differs depending on the account type:

For local users: An Admin manually selects the role from a dropdown menu during account creation.
For SSO users: Roles are mapped dynamically. Your IdP sends a specific attribute (for example, roles) during the login handshake, which Investigator maps to the internal admin, analyst, or viewer permissions.

Choosing an authentication method¶

Investigator supports two primary methods of authentication: Local user management and SAML SSO. Depending on your organization’s complexity, you may configure SSO for a single domain or deploy a multi-domain SSO architecture.

Use the table below to determine the best method for your deployment.

Method	Best for…	Key benefits
Local user management	Small teams: Environments with few users where centralized IdP management is unnecessary. Isolated environments: Networks without centralized identity management. Backup access: Maintaining a local administrator for emergency backup when SSO is enabled.	Simple setup with no external dependencies Total control within Investigator Essential for disaster recovery
SAML SSO: Single-domain	Enterprise teams: Organizations with a centralized Identity Provider (IdP) (for example, Okta or Azure).	Centralized password management Automatic user creation (JIT provisioning) Seamless login experience
SAML SSO: Multi-domain	MSSPs & complex orgs: Administrators managing users across different approved email domains.	Support for up to 30 distinct approved domains Unified login portal for diverse user groups Flexible access for partners/subsidiaries

Recommended setup: SSO with local backup¶

Adopting an authentication architecture that combines centralized SSO for daily use with an independent local administrator for emergency backup is a security best practice. This approach provides streamlined daily access while ensuring system availability during unforeseen IdP outages.

Standard access (SSO): Configure SAML SSO for all daily users (Analysts and Viewers). This streamlines the login experience and centralizes identity management within your IdP.
Emergency access (Local): Maintain at least one dedicated local administrator. This ensures you can bypass SSO and log in directly using the standard email/password fields if the IdP becomes unavailable.

Important

Do not use your standard company email for this local administrator. Create this account using an email address from a non-SSO domain (for example, admin@gmail.com rather than admin@yourcompany.com).

If a local account uses an email address that matches an approved SSO domain, the account is automatically converted to an SSO user upon the first login. Once linked, it can no longer be used as an independent local backup.

Next steps¶

See Configuring SAML Single Sign-On for full details and preparatory steps required to set up this architecture.