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 via SSO, 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 default role (Viewer); an Admin promotes them as needed
- The emailed sign-in code keeps working, so a misconfiguration can never lock your team out
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 endpoint, 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.lastNameAssign 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 and whose domain is auto-provisioned. 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 invite the person directly from 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 never 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 rather than retry, 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 registered with our identity broker for you automatically — one DNS TXT record, once.
Roles
Viewer
Read-only access to dashboards, metrics, patterns, and insights
Editor
Everything in Viewer, plus generate reports
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, Just-In-Time (JIT) provisioning is enabled for that domain.
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 default role (Viewer)
- 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 in the Auditty dashboard:
- 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 |
| Manage integrations (vault replay) | Not allowed | Not allowed | Allowed |
| Manage users and roles | Not allowed | Not allowed | Allowed |
| View audit log | Not allowed | Not allowed | Allowed |
Suppression and interception rules are not managed from the Auditty UI — they live in Edge’s own configuration (Helm values.yaml / ConfigMap, or per-workload K8s annotations). Any team member with cluster access to update the Edge ConfigMap or annotations can change rules, independent of their Auditty role.
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)
- Integrations — creating and deleting log platform connections, vault replays
- Backfill access — viewing suppressed logs via backfill URLs (Verified and Locked modes only)
- Settings — domain verification, log cost configuration, 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 SSO/JIT provisioning 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 logged-in Auditty users can view backfill URLs. Requires full authentication via your SSO provider.
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, a 30-day cookie is set — 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 signs in via SSO. No manual DNS setup needed — if your team uses SSO, just 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.