Aad SAML
You set up aad saml by linking your cloud directory to your target app. You swap trust keys and map user attributes to app roles. Most teams use this flow to manage all company logins in one place. They create broad user groups in the directory and assign them to apps. When these groups are too wide, users get far more permissions than they need. A single login then opens the door to sensitive data and production tools. How the aad saml login flow works The login flow relies on trust between
SAML 2.0: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up aad saml by linking your cloud directory to your target app. You swap trust keys and map user attributes to app roles. Most teams use this flow to manage all company logins in one place. They create broad user groups in the directory and assign them to apps. When these groups are too wide, users get far more permissions than they need. A single login then opens the door to sensitive data and production tools.
How the aad saml login flow works
The login flow relies on trust between the identity provider and the service provider. Your cloud directory acts as the identity provider that holds user accounts and groups. The target app acts as the service provider that needs to know who visits. You start the setup by exchanging metadata files between the two systems. The directory gives the app a public signing key and a login URL. The app gives the directory a unique entity ID and a reply URL.
When a user tries to log in, the app redirects them to the directory. The directory checks the user password and runs any required multifactor checks. Once the user passes, the directory builds a signed XML message called an assertion. This message holds claims like the user email, name, and group IDs. The browser sends this signed message back to the reply URL of the app. The app checks the signature with the public key and starts a user session.
Mapping directory groups to app roles
A working login is only the first half of the setup process. You also need to tell the app what each person can do inside. Teams handle this by sending group claims inside the signed login assertion. You assign users to directory groups based on their job titles or teams. During login, the directory lists these groups inside the XML message. The target app reads the group list and matches it to an internal role.
This mapping step often causes problems as a company grows over time. Directory groups tend to map to coarse roles like admin, writer, or reader. If an engineer needs one small write permission, they often get the full admin role. Teams rarely clean up old group mappings because they fear breaking active workflows. Soon, dozens of users hold standing admin rights across your most critical systems. You also have to watch signing keys and rotate them before they expire.
SAML 2.0: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity federation solves and what it misses
Centralizing logins with SAML solves a major problem for IT and security teams. You get one place to enforce strong passwords and multifactor checks for everyone. When someone leaves the company, you disable one account to cut off their logins. You do not have to hunt down local accounts across fifty different tools. The directory log also shows you every time a user signs into an app.
Still, this login check stops working the moment the app session begins. SAML only decides who can enter the front door of the system. It cannot see or control what the user does after they log in. If an engineer connects to a production database, the directory sees one login event. It does not see the SQL queries or commands they run next. It cannot block a bad drop statement or mask card numbers and emails in results. To control live actions and protect data in flight, you need controls at the command level.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What happens when an AAD SAML signing key expires?
The target app rejects all new login attempts because it cannot trust the signature. You must upload the new public key from your directory to the app before expiration.
Can AAD SAML restrict which database queries a user can run?
No, SAML only passes user identity and group claims during the initial login handshake. It has no awareness of database sessions, SQL statements, or CLI commands after login.
Why do group claims sometimes fail to map to app roles?
The directory often sends group object IDs instead of plain group names in the assertion. You must match those exact IDs in the app role settings so the mapping works.