Saml2 Flow
A saml2 flow logs a user into an app through a central identity provider. The identity provider checks the user and sends a signed XML file back. Engineering teams use this setup so people log in with one main account. It keeps staff from making new passwords for every single tool they use. Still, teams often attach broad admin roles to the groups in that XML file. Once the login check finishes, the user holds wide power across the app. How a saml2 flow works step by step Every saml2 flow br
Data Flow Diagrams (Security): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A saml2 flow logs a user into an app through a central identity provider. The identity provider checks the user and sends a signed XML file back.
Engineering teams use this setup so people log in with one main account. It keeps staff from making new passwords for every single tool they use. Still, teams often attach broad admin roles to the groups in that XML file. Once the login check finishes, the user holds wide power across the app.
How a saml2 flow works step by step
Every saml2 flow brings three parts together to complete a login request. These three parts are the user browser, the service provider, and the identity provider. The service provider is the app that the person wants to open. The identity provider is the central system that holds the team directory.
You can start the login from the app or from the central dashboard. In the app path, the person opens the service provider login page first. The service provider builds a login request and redirects the browser right away. The browser carries that request over to the central identity provider login screen.
Next, the identity provider asks the user for a password and a second factor. If the user already has an active session, the system skips this prompt. Once the check passes, the identity provider builds an XML document called an assertion. It signs this XML document with a private key so nobody can alter it.
The identity provider sends this signed assertion back through the user browser. The browser posts the XML payload to a specific endpoint on the service provider. The service provider checks the digital signature using a stored public key certificate. It also checks the time stamps to make sure the assertion is still fresh.
After the signature check passes, the service provider reads the user attributes inside. These attributes hold the user email address and a list of group names. The app matches those group names to its own local roles and permissions. Finally, the app issues a local session cookie and lets the user in.
Data Flow Diagrams (Security): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the login check solves and what it misses
This XML login setup solves account sprawl across a growing engineering team. You do not need to create local passwords on every single server or tool. When someone leaves the company, you disable their main account in one place. That person loses login rights to every linked service provider right away.
You also get a clear log of every login event in one central place. Security teams can see who logged in, when they did it, and from where. They can enforce strong multi-factor rules before the identity provider signs any XML assertion.
Still, a saml2 flow only handles the front door of the app. Once the service provider issues a local session, the identity provider steps away. The identity provider does not watch what the user does inside that active session. It only knows that the user passed the login check at the start.
This gap causes trouble when teams map directory groups to broad backend roles. An engineer might log in through single sign-on and land in a full admin role. From there, they can run any command or read any table without another check. If a query returns sensitive emails, phone numbers, or card numbers, nothing rewrites those fields.
The login flow also does not work well for databases or command-line tools. Those backend systems expect direct network protocols rather than browser redirects and XML posts. Teams end up sharing static database passwords alongside their clean web login setup. To stay safe, teams must pair identity checks with controls over live commands and queries.
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
What is the difference between SP-initiated and IdP-initiated login?
In an SP-initiated flow, the user starts at the app and gets redirected to log in. In an IdP-initiated flow, the user clicks the app icon inside their central login portal. SP-initiated login is safer because it helps prevent cross-site request forgery attacks.
How do groups map to permissions in a saml2 flow?
The identity provider puts the user group names inside the signed XML attribute statement. When the service provider reads the XML, it matches those group names to local roles. The user then gets all permissions tied to those local roles for the whole session.
Why do SAML assertions fail validation during setup?
Assertions often fail when the server clocks on the two systems drift apart. They also fail if the public certificate on the app does not match the signing key. Checking the audience URL and recipient URL fields fixes most other setup errors.