Identity-based Access
To set up identity based access, link your directory to your systems and assign roles. Each user logs in with their own profile instead of a shared key. Most teams start by mapping directory groups to broad system roles. When those roles are too wide, one mistake can expose or alter critical data. How identity based access works in practice In a standard setup, a central directory stores every user profile and group. When an engineer needs to work, they log in through the directory first. The
Identity and Access Management (IAM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To set up identity based access, link your directory to your systems and assign roles. Each user logs in with their own profile instead of a shared key. Most teams start by mapping directory groups to broad system roles. When those roles are too wide, one mistake can expose or alter critical data.
How identity based access works in practice
In a standard setup, a central directory stores every user profile and group. When an engineer needs to work, they log in through the directory first. The directory checks their password and second factor to confirm who they are. Then, it sends a signed token or claim to the target system.
The target system reads this claim and matches it to a local role. That role holds a list of rules that say what the user can do. For example, a developer role might allow reading tables in a test database. An admin role might allow creating new servers or changing network rules.
Teams also use this model for apps and scripts that run on their own. Instead of saving a static password in a file, the app gets a role. The platform gives the app a short token when it starts up. When a person leaves the team, admins disable their profile in one place. This cuts off their ability to log in across all linked systems at once.
What native roles solve and what they miss
Linking logins to real people fixes the problem of shared admin passwords. You no longer have ten engineers using the same root key to log in. Audit logs show which person opened a session and when they did it. You also avoid the chore of rotating shared keys every time someone leaves.
Still, native roles only check who logs in at the start of a session. Once the session opens, the user holds every permission in that role at all times. If an engineer needs write rights for one fix, they keep them all day. A typo in a query or script can still delete rows or drop tables.
Identity and Access Management (IAM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native roles also struggle to filter sensitive fields inside a table or response. If a role allows reading a customer table, the query returns every column by default. That result often includes raw emails, phone numbers, card numbers, or national IDs. Standard directory roles cannot rewrite matched fields in results while a query runs.
Steps to tighten role rules across your team
Start by listing every shared account that still exists in your systems. Replace those shared accounts with links to your central directory groups. Split large groups into smaller ones based on daily tasks and real needs. Give each group the smallest set of read rights needed for daily work.
Keep write and admin roles empty by default so nobody holds them all day. When an engineer needs to run a change, review the exact action first. Check the logs each week to find unused roles and remove them right away. This habit keeps your permission map clean and reduces the risk of accidents.
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 is identity based access different from role based control?
Identity models tie rules to a specific person or service profile first. Role models group permissions by job title, which both methods often use together.
Why are static keys risky for team logins?
Anyone who copies a static key can log in without proving who they are. If that key leaks, you cannot tell which person ran a harmful command.
Can directory groups stop someone from reading sensitive columns?
No, directory groups only decide who can log in and assume a system role. Filtering emails or card numbers in results requires checks on the live data stream.