Prerequisites
- An Authdog tenant, project, and non-production environment.
- Console access to configure authentication, organizations, users, roles, and restrictions.
- A backend that validates the Authdog session on every protected request.
- At least one recovery sign-in method for operators while enterprise SSO is being tested.
- For enterprise federation, access to the customer's SAML or OIDC identity-provider settings.
Decide the boundary before configuring anything: separate projects for separate products, separate environments for dev/staging/production, and organizations for customer companies within one environment. A user can belong to multiple organizations with different roles in each.
Implementation
Create the environment structure. Each environment has its own signing keys, connections, user store, and authorization model. Configure and test in development first; never reuse a development public key in production.
Choose sign-in methods. Enable only the methods your application supports: password, social OAuth, magic-link, passkey, TOTP MFA, or enterprise SSO.
Choose the user experience. The hosted Account Portal supplies sign-in, sign-up, MFA, and account management without a redeploy. Prebuilt components are the alternative when auth must render inside your layout.
Create organizations and memberships. One organization per customer company. Removing a membership removes access to that organization without deleting the user's account or other memberships.
Define server-enforced authorization. Choose one model, RBAC, ABAC, or FGA, per environment. For RBAC, define granular permissions and assign roles through memberships. Client-side checks improve UX; they are not a boundary.
Configure enterprise SSO. In Authentication → Providers, filter to Enterprise, choose a connector, and exchange configuration values with the IdP. Add non-overlapping email domains for discovery and use Test before rollout.
Restrict onboarding where appropriate. In Lidar → Restrictions, choose public, restricted, or waitlist sign-up, with optional domain allowlists/blocklists and disposable-email controls.
Add customer-managed setup when needed. The Admin Portal can issue a short-lived, organization-scoped setup link, generated only from trusted backend code after authorizing the customer administrator.
Security considerations
- Keep SAML certificates and OIDC client secrets out of browser code; use HTTPS everywhere and track certificate expiry.
- Avoid overlapping SSO discovery domains, resolution can become unpredictable.
- Maintain a recovery route while changing federation or MFA policy.
- Treat organization selection as untrusted input until matched against a validated membership.
- Review administrative activity using Audit logs.
Validation checklist
- Development and production use different environments and public keys.
- A user in two organizations sees only data for the active organization.
- Removing one membership blocks that organization's data without affecting another.
- SSO test verifies stable subject, email claims, and callback URL.
- An unrecognized SSO domain does not route to another customer's connection.
- Restricted sign-up blocks unauthorized self-service registration.
Troubleshooting
If SSO discovery selects the wrong connection, remove overlapping parent or subdomains. If users authenticate but see the wrong customer data, debug backend organization scoping before changing Authdog roles, confirm every data query uses the selected organization. If the Admin Portal link opens the wrong task, generate a new one for the correct environment and intent.
Next steps
- Add operational review procedures with Audit logs.
- Harden sign-up and response controls with Threat mitigation.
- Standardize hosted configuration using No-code identity flows.
- Route verified identity events with SIEM security events.