LDAP SAML Gateway
An ldap saml gateway translates old directory login requests into modern SAML assertions for web apps. You set it up by linking your local user directory to a SAML service. Many engineering teams use this setup to keep one central user list across old servers. Still, broad directory groups often grant too much power to users after they log in. How an ldap saml gateway works in practice Legacy directories store user names, passwords, and group names in a tree structure. Modern cloud apps do no
SAML 2.0 + LDAP Directory Services: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An ldap saml gateway translates old directory login requests into modern SAML assertions for web apps. You set it up by linking your local user directory to a SAML service. Many engineering teams use this setup to keep one central user list across old servers. Still, broad directory groups often grant too much power to users after they log in.
How an ldap saml gateway works in practice
Legacy directories store user names, passwords, and group names in a tree structure. Modern cloud apps do not read this tree directly. Instead, they expect signed XML tokens from a trusted identity provider. The translation service sits between your old directory and these modern apps. When a user tries to log in, the app sends a request to the service. The service asks the user for their directory name and password. Next, it checks those details against the local directory server using a bind request. If the check passes, the service reads the user group list from the directory. It then packs those group names into a signed SAML token. Finally, it sends that token back to the target app to start the session.
Mapping directory groups to app roles
Setting up the login flow is only the first step for your team. You also need to map directory groups to specific roles inside your target systems. The directory holds attributes like mail, department, and group membership for each person. Your translation service reads these attributes during the login check. You must write rules that match directory group names to target role names. For example, a database admin group in the directory maps to a write role. A support group maps to a read role in the same system. If a user belongs to several groups, the service sends all matching roles. You must check these mappings often so old group names do not grant bad permissions. Clear naming rules help admins see who gets which role during a login.
What directory translation solves and what it misses
Bridging your directory to SAML solves the problem of scattered user accounts. Admins can cut off a user in one directory to block all app logins. Teams do not need to manage separate passwords for every database or internal tool. Still, this login check only decides who can open a session at the start. Once the session starts, the translation service steps out of the way. It cannot see what queries or commands the user runs inside the system. A user in a broad directory group keeps full power for the whole session. If a developer runs a bad drop table command, the login bridge cannot stop it. Also, directory logs only show when a user logged in. They do not log the exact rows read or changed during that work session. Also, the login service cannot rewrite sensitive fields like emails or card numbers in results.
SAML 2.0 + LDAP Directory Services: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Can I use my existing directory groups for role assignments?
Yes, the translation service reads group attributes during the directory check. It sends those group names inside the SAML token so apps can assign roles.
What happens when a user leaves the company?
When you disable the user in the main directory, future login checks fail right away. Note that active sessions in target apps may keeps the session active until their tokens expire.
Does SAML translation protect sensitive data inside databases?
No, SAML only handles the initial login step between the user and the app. It does not inspect queries or mask fields like phone numbers or national IDs.