The Hard Part of SSO Is Knowing What to Reject

Key takeaways

• SAML carries authentication claims from a company’s identity provider to the services employees use.
• A valid signature is only one part of deciding whether to accept a login.
• XML signature wrapping exploits a mismatch between the data an application verifies and the data it uses.
• Supporting different SAML integrations requires explicit rules about which messages to accept and reject.

One company account gets you into your collaboration tools, HR portal, and other workplace apps. That convenience depends on each app correctly deciding which authentication messages to trust. With SAML, getting a login to work is only half the job: the other half is making sure the wrong ones fail.

Your app is accepting a claim, not checking a password

SAML stands for Security Assertion Markup Language. The name is cumbersome; its role in single sign-on is easier to explain.

The company’s authentication system, called the identity provider, or IdP, checks who you are. The application you want to use is the service provider, or SP.

The IdP sends the service a message containing the authentication result. Within that message, an assertion carries claims about the user and their authentication. Think of it as a statement saying, “We authenticated this person this way.”

That lets workplace applications rely on the company’s authentication system instead of each collecting and checking your company password.

But the responsibility hasn’t disappeared. It has moved. The application now needs to decide whether that statement is trustworthy and applicable to this login.

A genuine signature doesn’t grant universal access

SAML messages use XML. A digital signature can establish the integrity of the data it covers and connect it to a signing key.

That is useful. It is also a narrower guarantee than “this person should be allowed in.”

First, the application must establish that the signature comes from a key it trusts for the configured IdP. A signature that checks out mathematically isn’t enough.

Then the application must check the conditions attached to the authentication result:

• Was it issued for this service?
• Is it within its permitted validity period?
• Does it fit the current login flow?
• Is someone replaying a message that has already been used?

An authentication result issued for another service doesn’t become acceptable just because its signature is intact.

A real employee badge doesn’t open every office building. Who issued it matters. So do the doors it authorizes and when it expires.

Verify the data you actually use

XML signatures can cover particular elements identified by references within a document. Successfully verifying one element doesn’t automatically make every other element trustworthy.

That distinction creates room for XML signature wrapping.

In a vulnerable implementation, the signature checker and the login handler can end up reading different elements. The checker verifies a legitimately signed assertion. The login handler then picks up attacker-controlled data elsewhere in the document and uses it to identify the user.

The attacker hasn’t forged the signature. They’ve exploited a disagreement inside the application about which data matters.

This isn’t an inherent vulnerability in every SAML product. It affects implementations that fail to keep the verified element connected to the authentication data they actually consume.

“There’s a valid signature somewhere in this document” is the wrong security test. The useful question is whether the exact data used for login received the required verification.

Compatibility means more conditions to enforce

Enterprise applications need to connect to different customers’ identity systems. Those systems may place signatures differently, identify users differently, or send different attributes.

Variation alone isn’t a vulnerability. The challenge is preserving the necessary checks across every supported combination.

One integration might use a signature covering the response. Another might use a signature on an assertion inside it. Either way, the authentication information the application consumes must be protected by a trusted signature.

How the login begins matters, too. When the service initiates it, the application can check that the response matches its request. When a user starts from the IdP’s app launcher, there is no preceding service request to match. That flow needs its own handling.

This is why SAML’s complexity can feel fractal. Open up one validation step and several more appear inside it. The application has to interpret the document structure, signature coverage, and login flow together.

Compatibility exceptions therefore need precise boundaries. For each customer, which issuer and keys are trusted? Which message forms are allowed? Relaxing validation until an integration works can turn a convenience feature into an opening for an attacker.

SAML makes single sign-on possible by letting applications accept another system’s authentication decisions. That trust needs a narrow, explicit scope. The next time you review an SSO integration, ask it to demonstrate a login it correctly refuses.