[jiggawatts]

I've been cavorting around that minefield recently. I still have some of my legs and a tiny bit of my sanity.

The most recent "fun" I had was that on a Citrix NetScaler, if you enable a certain n-Factor workflow, it sends a SAML request to the IdP that Microsoft products only reject as "invalid XML".

From what I can gather the XML being sent is perfectly valid. The issue must be something hideously subtle, like the white space or UTF-8 encoding being subtly different that is upsetting the Microsoft SAML implementations, but not any others.

Have a look at some SAML XML examples online: https://www.samltool.com/generic_sso_res.php

They're hideous not because they're XML, but because they're bad XML! The SAML standard defines its own "namespace attributes" separately but on top of the XML namespaces!

Similarly, instead of the straightforward way to encode the data:

    <tag prop="attr">value</tag>

They abstract one level up unnecessarily:

    <element name="tag">
        <attribute name="prop">attr</attribute>
        <content>value</content>
    </element>

This is the same mistake people make in database schema design, where they'll have a table with columns called "Key", "ColumnName", and "ColumnValue".

[userbinator]

The issue must be something hideously subtle, like the white space or UTF-8 encoding being subtly different that is upsetting the Microsoft SAML implementations, but not any others.

That is almost certainly the case, as another comment here indirectly references: https://news.ycombinator.com/item?id=25422734

[ikiris]

oh wow that's disgusting, why would someone design something like this.

[jiggawatts]

It's the most egregious example of design-by-committee that I have ever seen.

Everything about SAML is about 10x more complex than it technically needs to be.

On top of that, it has so many optional features that interoperability problems are likely even between 100% standards compliant implementations.