User Management & Access

SSO authentication, roles, and team onboarding

Authentication

Auditty has no passwords. Your team signs in with their corporate email at app.auditty.ai in one of two ways:

Emailed sign-in code

Works immediately, nothing to configure. The user enters their email and receives a one-time code.

Your identity provider

Okta, Microsoft Entra ID, Google Workspace, or any SAML 2.0 / OIDC provider. Set it up yourself in about ten minutes.

The two coexist. Turning on SSO does not lock out anyone mid-setup; the emailed code remains available as a fallback.

Connect Your Identity Provider (SSO)

Auditty supports SAML 2.0 and OpenID Connect (OIDC); use whichever your organization standardizes on. Setup is entirely self-service: an Auditty Admin starts it from Settings → Single Sign-On. There is no support ticket to file and no configuration values to email back and forth.

Step 1: Verify your email domain

Under Settings → Email Domains, add and verify your corporate domain (see Domain Verification below). Sign-ins are routed to your identity provider by email domain, so this must be in place first. If anyone from your domain has already signed in (through your identity provider or with an emailed code), the domain is verified automatically and there is nothing to do.

Step 2: Open the setup wizard

Go to Settings → Single Sign-On and click Set up SSO. A guided wizard opens in a new tab, listing every major identity provider. The link is single-use and expires after 10 minutes; generate a fresh one whenever you need it, and share your screen with your IdP admin or hand the link straight to them.

Step 3: Your IdP admin completes the wizard

The wizard shows the exact values to paste into your identity provider (the ACS URL and Entity ID for SAML, or a redirect URI for OIDC) with screenshots for each step. Your admin creates the app, pastes those values in, sends the app metadata back through the same wizard, and assigns the relevant users or groups.

These values are unique to your organization. Do not reuse values from another vendor integration or another Auditty tenant.

After setup:

Settings → Single Sign-On shows the connection as Active, naming the provider it is connected to
Anyone with an email address on your verified domains is routed to your identity provider automatically
First-time users are provisioned on sign-in with the domain’s default role (Viewer unless you change it under Email Domains); an Admin promotes them as needed
The emailed sign-in code keeps working throughout, so your team can always sign in while you set this up

Adding a tile to your IdP dashboard

The SAML app you created in the setup wizard already appears as a tile; clicking it signs the user straight in, with no extra configuration and no RelayState to set. A bookmark app pointing at https://app.auditty.ai (Okta calls it a Bookmark App; Entra ID a non-gallery link) works equally well, and is the only option for an OIDC connection.

A tile click is handed to Auditty’s own sign-in, so it becomes an ordinary sign-in that we started; the user is passed straight through, since they are already authenticated with your identity provider. If anyone is ever asked to confirm the sign-in, that is a one-time security check rather than a fault: approving it is all that is needed, and no domain or DNS record is involved.

Answers for Your Identity Provider Team

IdP onboarding teams usually work from a standard intake form. Every answer is below, so you can forward this page instead of scheduling a call. The two per-organization values (ACS URL and Entity ID, or the OIDC redirect URI) appear inside the setup wizard.

Question	Answer
Supported protocols	SAML 2.0 and OpenID Connect (OIDC); either is fine
ACS URL / Entity ID (SAML)	Shown in the setup wizard, unique to your organization
Sign-in redirect URI (OIDC)	Shown in the setup wizard
Required attributes	`email`, `firstName`, `lastName`
NameID format	Unspecified (the default) is fine. For Okta, set Application username to the custom expression `user.getInternalProperty("id")` so a later email change does not orphan the account
Group claims	Not required and not consumed. Auditty roles are managed on the Users page
Signing	Your provider's default signed assertion is expected. Signed responses and encrypted assertions are not required
OIDC flow	Authorization Code with a client secret (confidential). PKCE not required
OIDC scopes	`openid`, `profile`, `email`
OIDC claims	`sub`, `email`, `given_name`, `family_name`
Refresh tokens	Not required; Auditty issues its own short-lived session
Base URL	`https://app.auditty.ai`
Sign-out redirect URI	None. Signing out clears the Auditty session and returns to our login page; it does not sign the user out of your IdP
SP metadata XML	Not published. The ACS URL and Entity ID from the wizard are the complete service provider configuration
IdP-initiated SSO	Supported for SAML. The tile from your SAML app signs users straight in; no `RelayState` is needed
SCIM / Directory Sync	Not supported yet; see User Offboarding below

Okta attribute statements (Sign On tab → SAML attribute statements):

email      → user.email
firstName  → user.firstName
lastName   → user.lastName

Assign users in your identity provider

A completed connection still rejects everyone until users or groups are assigned to the app on your side (Okta: the app's Assignments tab). This is the most common reason a fresh SSO setup "does not work".

User Offboarding

Auditty does not support SCIM / Directory Sync yet, so removing access is an explicit action. Either is sufficient:

Unassign the user from the Auditty app in your identity provider: they can no longer sign in via SSO, effective immediately
Remove the user on the Users page: deletes their Auditty account and access entirely

While the emailed sign-in code remains available, unassigning in your IdP alone does not prevent sign-in for a user whose account still exists in Auditty. Remove the account on the Users page to fully revoke access.

SSO Troubleshooting

A teammate sees "Your account is not set up yet"

Their email domain is not verified for your organization, or auto-provisioning is off for it. Check Settings → Email Domains, or create the account directly with Create User on the Users page, useful for contractors on a different domain.

We finished the wizard but sign-in is still rejected

Two usual causes: users or groups are not assigned to the app in your identity provider, or the connection has not yet reached Active. Settings → Single Sign-On shows the live state; "Setup incomplete" means the wizard has remaining steps.

Clicking our IdP tile opens the Auditty login page instead of signing in

A SAML tile signs users in directly. If it lands on our login page, the usual cause is that the tile belongs to a different app than the connection Auditty is using, or the user is not assigned to the SAML app. An OIDC connection cannot provide a tile at all; use a bookmark app pointing at https://app.auditty.ai, which passes the user straight through because they are already signed in to your IdP.

A user was asked to confirm the sign-in after clicking the tile

A one-time security check, not a fault, and nothing to configure, no domain or DNS verification is involved. Approving it signs the user in; they are not asked again. Anyone who answers no is told to contact you, and to start again from app.auditty.ai if they cancelled by mistake, since a refusal is what an attempted impersonation would look like.

Can we require SSO and disable the emailed sign-in code?

Not a self-service setting today; contact Auditty support to discuss enforcing SSO-only sign-in for your organization.

Do we need to verify our domain twice?

No. The domain you verify in Auditty is all that is needed: one DNS TXT record, once.

Roles

Viewer

Read-only access to dashboards, metrics, patterns, and insights

Editor

Everything in Viewer, plus generate reports and author fleet rules

Admin

Full access: manage users, integrations, vault replay, and audit log

Domain Verification & Team Onboarding

To enable automatic team onboarding via SSO, an Admin must verify your organization's email domain. Once verified, any team member with a matching email address can sign in and is automatically provisioned.

Step 1: Add Your Domain

Navigate to Settings → Email Domains and add your corporate email domain (e.g. yourcompany.com). The system generates a unique verification token.

Step 2: Add DNS TXT Record

Create a DNS TXT record for _auditty-verify.yourcompany.com whose value is exactly the verification token shown in Settings (no prefix, no extra text). This proves domain ownership.

_auditty-verify.yourcompany.com  TXT  "auditty-verify-xxxxxxxxxxxxxxxx"

Step 3: Verify

Click Verify in Settings. The system checks your DNS record and activates the domain. Once verified, anyone from that domain is provisioned on their first sign-in.

After Verification:

Team members go to app.auditty.ai and sign in with their corporate email
They're automatically added to your organization with the domain's default role (Viewer unless you change it)
An Admin can then promote them to Editor or Admin as needed

Note: Public email providers (gmail.com, outlook.com, yahoo.com, etc.) cannot be claimed as organization domains.

Managing Users

Admin users can manage their team from the Users page:

View all team members and their roles
Change roles: promote or demote users (Viewer, Editor, Admin)
Remove users: revoke access for team members who no longer need it

Who Can Do What

Capability	Viewer	Editor	Admin
View dashboards, metrics, patterns	Allowed	Allowed	Allowed
Generate reports	Not allowed	Allowed	Allowed
Author fleet rules on the Fleet Rules page	Not allowed	Allowed	Allowed
Switch the fleet into or out of shadow mode (an Editor can still author an unscoped measure rule, which is the same thing)	Not allowed	Not allowed	Allowed
Manage integrations (vault replay, Sync Monitors)	Not allowed	Not allowed	Allowed
Manage users and roles	Not allowed	Not allowed	Allowed
View audit log	Not allowed	Not allowed	Allowed

Rules reach Edge from three places, and only one of them is governed by Auditty roles. Fleet rules are authored on the Fleet Rules page by editors and admins and audited here. ConfigMap and annotation rules live in Edge’s own configuration (Helm values.yaml, or per-workload K8s annotations): any team member with cluster access to change them can, independent of their Auditty role, and a local rule with the same name as a fleet rule overrides it on that node, which the Fleet Rules page shows as “overridden locally”.

Audit Log

The Audit Log provides a complete record of all significant actions taken within your organization. Only Admin users can access the Audit Log.

Tracked actions include:

Authentication: user logins, logouts, and failed sign-in attempts
Authorization: denied access attempts (a user trying an action above their role)
User management: creating, updating roles, and removing team members (each change records a required justification)
Fleet rules: every rule created, updated, enabled, disabled or deleted, the shadow-mode switch included, since it is the fleet rule measure
Integrations: creating and deleting log platform connections, vault replays
Backfill access: viewing suppressed logs via backfill URLs (Verified and Locked modes only)
Plan & Usage: changes to the log cost savings are priced at and to the monthly Auditty cost
Settings: domain verification, public replay and backfill access settings
Reports: performance report generation

Justification on access changes

Every change to access permissions (granting, changing, or revoking a role, and adding an SSO auto-provisioning domain) requires a justification, captured alongside the time of change, the affected user, and the old/new privileges. Automatic provisioning on first sign-in records a system-generated reason noting the verified domain that authorized the grant. This gives you a complete, defensible record of who changed what access, when, and why.

Auditty Admin Actions

When an Auditty support team member performs an action on your behalf, the audit log entry is clearly marked with an Auditty Admin badge so you always know who made the change.

Every entry records the identity (who), the affected resource (what), the event type, a timestamp, the origin (IP address and user agent), and a success/failure status, so both successful actions and denied/failed attempts are captured. The Audit Log supports filtering by action type and date range, and entries can be exported to CSV for compliance reporting.

Backfill Link Access Control

Admins can control who can view suppressed logs via backfill URLs. Navigate to Settings → Backfill URL Access to choose one of three access levels:

Open

Anyone with the backfill link can view logs. No identity check required.

Verified (default)

Viewers verify their identity via Google or Microsoft sign-in. Email domains are checked against your configured domains, auto-verified from SSO login, no DNS setup needed.

Locked

Only signed-in members of your organization can open backfill links; a signed-in user from another organization is refused.

How Verified Mode Works:

A developer clicks a backfill link from a suppression summary
They see a clean verification page: "This log archive is shared by [Your Company]"
They click "Continue with Google" or "Continue with Microsoft": one click, already signed in
Their email domain is checked against your configured domains in Settings (DNS verification not required)
If the domain matches, the browser is remembered for 30 days, no re-verification needed for subsequent links
No Auditty account is created. The viewer is ephemeral.

Same model as Google Docs link sharing. "Anyone in your organization with the link can view." Security teams understand this immediately.

Zero-Config for SSO Tenants:

Domains are automatically verified when any user from them signs in, and auto-provisioning is switched on for them with the Viewer role. No manual DNS setup needed: once your team has signed in, set the access level to Verified and it works immediately.

Audit trail: In Verified and Locked modes, every backfill URL view is recorded in the audit log with the viewer's identity, namespace, workload, time range, IP address, and user agent. Open mode does not generate audit entries (no identity to record).

Tenant isolation: Each organization's data is completely separated. Users can only see data belonging to their own organization.