SAML Is Insecure by Design

Re:SAML Is Insecure by Design by solatic on Friday August 06, 2021 @01:17AM (#28083563)

There's a reason for that. The attribute statement / attribute name / attribute value style has a consistent schema that won't change despite any custom attributes that are being added. Your "claims" example does not have a consistent schema; it changes when new claims are added, and therefore makes it impossible to validate the response (the notion of arbitrary objects does not exist in XML schemas).

[ Parent | on HN ]

Re:SAML Is Insecure by Design by jiggawatts on Friday August 06, 2021 @04:18AM (#28084519)

Typically this would be implemented by having a set of predefined elements in the XSD (name, email, etc...) and also an 'additional' element that has a list of "Any" as the children. Easy!

E.g.:

    <claims>
        <nameid>[email protected]</nameid>
        <givenname>Foo</givenname>
        <surname>Bar</surname>    
        <extensions>
            <myCustomClaim>010231239dfadsf</myCustomClaim>
        </extensions>
    </claims>

It's also possible to use namespaces for extensibility, and this can even be used to guarantee that the tag names don't conflict.

So instead of this garbage:

    <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>

You'd have standard namespaced and extensible elements such as:

    <claims xmlns:saml="urn:oasis:names:tc:SAML:2.0:ac:classes" xmlns:adfs="urn:com:microsoft:ADFS">
        <saml:nameid>[email protected]</saml:nameid>
        <saml:givenname>Foo</saml:givenname>
        <saml:surname>Bar</saml:surname>    
        <adfs:securityId>S-0-1-52534-12362341234-12312315</adfs:securityId>
        <adfs:objectGuid>47e3a2d3-266a-48ad-b080-b785b4d0b45f</adfs:objectGuid>
    </claims>

This would enable clients to validate the claims they do understand and ignore the claims they don't. Similarly to how X.509 does it, elements could be added to "must process" or "optional" parent elements to ensure correctness and security even in the face of a wide range of client capabilities.

This is common in the XML world, but SAML had to invent its own wheels.

[ Parent | on HN ]

Re:SAML Is Insecure by Design by hvidgaard on Friday August 06, 2021 @02:12AM (#28083862)

Surely there are better ways to do that, if it is even needed. If your validation only validates that you have

> attribute statement / attribute name / attribute value style

Does that even have a benefit? Is it any different that simply validating that a string is valid xml/json/something syntax?

[ Parent | on HN ]