Microsoft 365 SAML
You set up microsoft 365 saml by linking your cloud directory with your target app. This link lets your team log in with one work account across many tools. Most teams start by sharing trust keys and login URLs between both systems. They then map directory groups to app roles so people get their permissions. Problems start when admins map large groups to broad admin roles to save time. That shortcut gives too many users the power to change or delete live data. How microsoft 365 saml works in p
SAML 2.0 + Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up microsoft 365 saml by linking your cloud directory with your target app. This link lets your team log in with one work account across many tools. Most teams start by sharing trust keys and login URLs between both systems. They then map directory groups to app roles so people get their permissions. Problems start when admins map large groups to broad admin roles to save time. That shortcut gives too many users the power to change or delete live data.
How microsoft 365 saml works in practice
The sign-on flow uses two main parts to check who a user is. Your Microsoft cloud directory acts as the identity provider that holds user accounts. The target app acts as the service provider that needs to know the user. When a person opens the app, it sends a login request to Microsoft. The browser takes the user to the Microsoft login page to sign in. Microsoft checks the password and runs any multi-factor checks you have set up. Once the check passes, Microsoft builds a signed XML message called an assertion. This message holds the user email, group names, and a digital signature. The browser sends this signed message back to the target app right away. The app checks the signature against the public key you saved during setup. If the key matches, the app reads the group claims inside the message. It then matches those claims to its own local roles and starts a session.
How teams map directory groups to roles
Good role design keeps your systems safe after the first login step finishes. Teams often create one group for readers and another group for system admins. They put engineers into these groups inside the Microsoft admin portal. During login, the SAML message carries these group IDs over to the target app. The app sees the group ID and grants the matching local role. This works well for web apps that have clear role levels built in. It gets harder when engineers need to run commands on servers or databases. Many databases and command line tools do not read SAML assertions on their own. To fix this, teams often link SAML to a cloud role or shared account. Every engineer in the group then shares the exact same database role. If ten engineers share a write role, they all get full write power.
What single sign-on solves and what it misses
Setting up single sign-on solves a huge problem for IT and security teams. You no longer need to make or delete separate passwords in twenty different apps. When someone leaves the company, you turn off their main Microsoft account once. That single change blocks their login across every linked app right away. You can also enforce strong multi-factor rules in one central place. Yet single sign-on only checks who the person is at the front door. Once the session starts, SAML steps out of the way for good. It cannot see what queries an engineer runs inside a production database. It cannot stop a bad command from dropping a table by mistake. It also cannot rewrite sensitive fields like emails or card numbers in query results. Security teams see who logged in, but they miss what happened next. To close this gap, you need controls that watch commands and queries in flight.
SAML 2.0 + Microsoft Entra ID (Azure AD): 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
What is the difference between the identity provider and service provider?
Microsoft acts as the identity provider that checks passwords and user groups. The app your team wants to use acts as the service provider. Microsoft proves who the user is, and the app lets them in.
Why do SAML logins fail when a signing certificate expires?
The target app uses a saved public key to trust messages from Microsoft. When that key expires, the app rejects every new login message for safety. You must upload the new key from Microsoft into the app to fix it.
Does SAML control what a user can do inside a database session?
No, SAML only handles the initial sign-on handshake and passes group names over. It does not inspect SQL queries or terminal commands after the session begins. You need session-level rules and data masking to control live database actions.