SAML Protocol
The saml protocol passes login data between an identity provider and a target app. You set it up by trading trust files and mapping user groups to roles. Most engineering teams use this standard to centralize how staff log in to tools. Still, teams often map broad identity groups to shared admin roles inside target systems. Once a user logs in, that broad role lets them run any command unchecked. How the saml protocol works in practice This XML standard links two main systems during a login f
SAML 2.0 + Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
The saml protocol passes login data between an identity provider and a target app. You set it up by trading trust files and mapping user groups to roles. Most engineering teams use this standard to centralize how staff log in to tools. Still, teams often map broad identity groups to shared admin roles inside target systems. Once a user logs in, that broad role lets them run any command unchecked.
How the saml protocol works in practice
This XML standard links two main systems during a login flow. The first system is the identity provider, which holds your user directory and passwords. The second system is the service provider, which is the app or database tool. Before users can log in, an admin links both systems using metadata files. These files hold public keys and web addresses for sending login messages.
A typical login starts when an engineer opens the target app in a browser. The app sees no active session and sends the browser to the identity provider. The identity provider asks the user to log in and check a second factor. Once that check passes, the identity provider builds a signed XML message called an assertion. This assertion lists the user email, group names, and a short time limit.
The browser carries this signed assertion back to the target app. The app checks the digital signature using the public key it saved earlier. If the signature is valid, the app reads the group names inside the message. It matches those group names to local roles and starts a new user session.
How teams map identity attributes to system roles
Passing a login check is only the first half of the setup. The target system still needs to know what the user can read or write. Admins handle this by sending group attributes inside the XML login message. For example, an identity provider might send a tag showing the user is in engineering.
Inside the target system, admins create a rule that reads this group tag. The rule maps the group tag to a local database role or server role. Because creating many small roles takes time, teams often make just two or three. Every developer in the group ends up getting the same broad write role. This keeps the directory setup simple, but it gives too much power to each account.
SAML 2.0 + Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What single sign-on solves and what it leaves open
Setting up single sign-on solves a major account management headache for security teams. Staff do not need to save separate passwords for every database tool or console. When someone leaves the company, an admin turns off one main directory account. That person loses login rights across every linked system right away. You also get a central log showing when and where each person logged in.
Still, the login check stops working the moment the session starts. It decides who gets through the front door, not what they do inside. Once the target app accepts the assertion, the user acts with full role rights. The login system cannot see or block a dangerous delete query in flight. It also cannot mask sensitive fields like emails, phone numbers, card numbers, or national IDs. To control real actions, teams must inspect commands and data during the active session.
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 is the difference between an identity provider and a service provider?
The identity provider checks who the user is and holds the main user directory. The service provider is the target app that trusts those checks to grant sessions.
What does a signed XML assertion contain?
An assertion holds the user ID, group attributes, a digital signature, and time limits. The target app reads this data to verify the user and assign a role.
Does single sign-on control what queries an engineer can run?
No, single sign-on only checks identity at the start of a user session. After login, the local role inside the database or server controls all user actions.