Domain Identity
A domain identity proves your team owns a specific web name and links users to one login directory. You set it up by adding text records to your DNS host to prove ownership to your cloud provider. Most teams link their main directory so engineers log in with their work email. Still, teams often attach broad admin roles to these groups to move fast. Broad roles let any user run risky commands across databases and servers. How to set up a domain identity Setting up a domain identity starts insi
Identity and Access Management (IAM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A domain identity proves your team owns a specific web name and links users to one login directory. You set it up by adding text records to your DNS host to prove ownership to your cloud provider. Most teams link their main directory so engineers log in with their work email. Still, teams often attach broad admin roles to these groups to move fast. Broad roles let any user run risky commands across databases and servers.
How to set up a domain identity
Setting up a domain identity starts inside your main user directory and DNS host. First, you register your company web name inside your cloud identity provider. The provider gives you a unique text token to place in your public DNS records. Next, you open your DNS host and add this token as a new record. The identity provider checks public DNS to confirm that your team owns the name.
Once the check passes, you link your user groups to cloud roles. You also set up trust rules using open standards like SAML or OIDC. When an engineer logs in with their work email, the system checks the domain name. It sends the user to your main login page to verify their password and second factor. After a good login, the directory sends a signed token back to the target service. The service reads the group claim in the token and grants the matching role.
For email tools, this setup also includes signing keys stored in DNS. Those keys let receiving servers check that messages truly come from your domain. In both cases, DNS records and cryptographic keys anchor trust to your web name.
What native domain trust solves and what it misses
A verified domain identity stops outsiders from claiming your company name on cloud platforms. It also ends the bad habit of making local user accounts on every database and server. When someone leaves the team, you disable one account in the central directory. That single action blocks their login across every linked app and cloud account.
Identity and Access Management (IAM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, domain checks only happen at the front door when a session starts. Once the user logs in, the target database or server trusts the whole session. The directory has no idea what queries or shell commands the user runs next. If a developer gets a broad role, they can read whole tables of customer data. Raw emails, phone numbers, and card numbers return in full to their screen. A central directory also cannot pause a single drop table command for peer review. It controls who enters a system, not what happens inside the active session.
Managing group roles across environments
To reduce risk, teams split roles by job function and by stage. Developers might get read roles in production and write roles in staging. You map each directory group to a narrow role in the target database or server. Even with split roles, maintaining hundreds of group mappings takes constant work. Teams often fall back to shared roles when an urgent production bug hits. Keeping sessions safe requires controls that inspect individual actions after the login check passes.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does domain identity differ from a single user account?
A domain identity represents your whole company name and proves ownership through DNS records. Individual user accounts live inside that verified domain and inherit its trust rules.
What happens if our DNS check record gets deleted?
Your cloud provider may mark the domain as unverified after its next routine check. Existing sessions often stay active, but new group syncs or email signing can fail until you restore the record.
Does verifying a domain restrict what queries a user can run?
No, domain checks only confirm who the user is during login. Database roles and runtime controls decide which queries or commands that user can run afterward.