Authdog
Platform guide

Enterprise Ready

Enterprise readiness starts with predictable identity operations: isolated environments, customer-specific SSO, automated provisioning, server-side authorization, and evidence that each control works. Authdog provides these building blocks without requiring every customer to share an identity provider or directory design. This guide turns them into a staged rollout plan without making assumptions about certifications, retention periods, or controls outside the product.

Prerequisites

  • An Authdog tenant, project, and separate environments for development, staging, and production.
  • A production application that validates Authdog sessions on the backend.
  • An organization model for B2B customers that need their own SSO or directory configuration.
  • Named owners for identity configuration, customer onboarding, support recovery, and access reviews.
  • A non-production test organization and test IdP tenant.
  • A role and permission design based on least privilege.

Each Authdog environment has its own signing keys, connections, user store, and authorization model. Treat environment configuration as deployment-stage configuration: validate in staging, then recreate and retest the intended shape in production.

Implementation

1. Establish environment boundaries

Use one project for an application and separate environments for development, staging, and production. Confirm that each deployment uses the public key for its intended environment. A session minted in one environment cannot validate against another environment's key.

Model each B2B customer as an organization inside the production environment. Users can belong to multiple organizations, and organization-scoped roles keep customer access separate. Do not create a separate Authdog environment for every customer unless deployment-stage isolation, rather than application tenancy, is the actual requirement.

2. Standardize authentication

Choose a supported sign-in surface: hosted Account Portal, embedded components, or custom flows. Enable only required methods in each environment. For enterprise customers, configure SAML 2.0 or OIDC connections and route users by email domain.

Keep customer setup repeatable. Authdog's Admin Portal can provide a short-lived, organization-scoped setup link for SSO, directory sync, or domain verification without granting access to the Authdog console. Generate these links from trusted backend code only, after confirming that the requester may administer the selected organization.

Follow Authentication and SSO for metadata exchange, discovery-domain rules, test sign-in, and recovery planning.

3. Automate joiner and leaver workflows

Use SCIM 2.0 when a customer's IdP is the source of truth. The console issues an environment-scoped bearer token for the /v1/scim/v2 service. The IdP can create, update, deactivate, and delete Users and Groups and change group membership.

Create group-to-role mappings so directory groups grant Authdog roles. Match by group display name or external ID, then re-apply mappings to existing groups when introducing a new rule. See User provisioning with SCIM.

Where provisioning is unavailable, document manual onboarding and offboarding through the user console. Suspension blocks new sign-ins; administrators can also inspect and revoke active user sessions.

4. Enforce authorization on the backend

Select one authorization model per environment:

  • RBAC for role-based job functions.
  • ABAC for Rego policies using user, resource, and request attributes.
  • FGA for relationship-based, per-object access.

Start with granular permissions and a small role set. Use client-side checks only to shape the interface; enforce every protected action on the server. Authorization and access control covers model selection and validation.

5. Build operational evidence

Use console audit views to investigate sign-ins, role changes, provisioning updates, and administrative actions. Filter by environment, time, event type, and user. Preserve raw event data before remediation when investigating an incident.

Use the Events API for reconciliation and webhooks for low-latency reactions where needed. Webhook consumers must verify the HMAC signature over the exact raw request body, reject stale timestamps, and deduplicate delivery IDs.

Security considerations

  • Keep API tokens, OIDC client secrets, SCIM tokens, and generated Admin Portal links out of browser code and logs.
  • Use HTTPS for SAML metadata, SSO, logout, OIDC discovery, and callback URLs.
  • Track SAML signing-certificate expiry and rotate before the IdP removes the old certificate.
  • Avoid overlapping SSO discovery domains; first-match resolution can otherwise route users unpredictably.
  • Keep a tested recovery sign-in path while changing SSO or MFA policy.
  • Rotate SCIM tokens deliberately: the previous secret stops working immediately.
  • Do not claim a fixed audit-log retention period or immutable archive. Export required evidence to controlled storage or a SIEM under your own retention policy.
  • Treat TOTP as a second factor, not phishing-resistant authentication.

Validation checklist

  • Development sessions fail validation against production configuration.
  • Each customer organization sees only its intended memberships and roles.
  • SAML or OIDC test sign-in succeeds with expected stable subject and verified email.
  • Discovery-domain users reach the correct active enterprise connection.
  • SCIM test user and group appear in the intended environment.
  • Upstream deactivation suspends the user and prevents continued session validation.
  • Group membership produces expected role and permission changes.
  • Protected backend routes deny missing, invalid, and insufficient sessions.
  • Operators can find related authentication and administrative events.
  • Recovery and token-rotation procedures have been exercised in staging.

Troubleshooting

Users reach the wrong IdP: inspect active connections and remove overlapping domain entries. A parent domain also matches its subdomains.

SSO works in staging but not production: compare the callback, ACS, entity ID, discovery URL, credentials, certificate, and active state. Values are environment-specific.

Provisioned user has no access: confirm the group arrived, mapping match type and value are correct, target role exists, and mappings were re-applied for existing groups.

Offboarded user still appears: suspension preserves the record and history. Check user state and session validation rather than expecting immediate record deletion.

Audit search returns nothing: verify environment and UTC time range, then broaden event filters. Event payload fields vary by source.

Next steps