xmlschema 3.0.1 broken dependency

christina-moore commented 8 months ago

Hi, I am using djangosaml2 to configure two applications, one as an SP and the other as an IDP. On 09/01/2024 xmlschema version 3.0.1 was released. Because xmlschema isn't pinned to a major version in pysaml2, my applications installing djangosaml2/pysaml2 picked up this new version of it. With the new version, authentication between the SP and IDP is broken with this error:

XML parse error: {'message': 'Signature verification failed. Invalid document format.', 'error': 'global xs:simpleType/xs:complexType \\'xs:string\\' not found"}

The XML decoded from the SAML response to the SP djangosaml2 ACS endpoint that is causing this failure looks like this (condensed):

<samlp:Response xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ID="id-Ar3NnAi1zPnebD1XG" InResponseTo="id-ooDCZnNICgVLxswml" Version="2.0" IssueInstant="2024-01-09T11:51:10Z" >
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        issuer
    </saml:Issuer>
    <ds:Signature Id="Signature1">
        Signature...
    </ds:Signature>
    <saml:Assertion Version="2.0" ID="id-JMxGKWX2KiyKUA8D9" IssueInstant="2024-01-09T11:51:10Z">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            issuer
        </saml:Issuer>
        <ds:Signature Id="Signature2">
            Signature...
        </ds:Signature>
        <saml:Subject>
            Subject...
        </saml:Subject>
        <saml:Conditions NotBefore="2024-01-09T11:51:10Z" NotOnOrAfter="2024-01-09T12:51:10Z">
            Conditions...
        </saml:Conditions>
        <saml:AuthnStatement AuthnInstant="2024-01-09T11:51:10Z" SessionIndex="id-RDLHvV8gWRO7PfVH9">
            Auth...
        </saml:AuthnStatement>
        <saml:AttributeStatement>
            <saml:Attribute Name="urn:oid:1.2.840.113549.1.9.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="email">
                <saml:AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
                    email
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="first_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml:AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
                    firstname
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="last_name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
                <saml:AttributeValue xsi:type="xs:string" xmlns:xs="http://www.w3.org/2001/XMLSchema">
                    lastname
                </saml:AttributeValue>
            </saml:Attribute>
            <saml:Attribute Name="urn:oid:2.5.4.12" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="title">
                <saml:AttributeValue xsi:nil="true" xsi:type="xs:string"/>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

As part of our SAML configuration we are passing various attributes. It seems the issue occurs when an attribute with a null value is passed, for example the final attribute in the XML above:

<saml:Attribute Name="urn:oid:2.5.4.12" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" FriendlyName="title">
    <saml:AttributeValue xsi:nil="true" xsi:type="xs:string"/>
</saml:Attribute>

The xs:string type is not recognised because the namespace isn't included in the AttributeValue (xmlns:xs="http://www.w3.org/2001/XMLSchema"). I believe this is happening now that xmlschema defaults to stacked namespaces rather than its previous behaviour of collapsing namespaces.

Code Version

djangosaml2 version 1.7.0 pysaml version 7.3.0 xmlschema 3.0.1

Possible Solution

We have temporarily pinned the xmlschema dependency by including it in our app dependencies. I wanted to get your thoughts on if it makes sense to pin the dependency within this repo to a major version?

Another potential solution is to modify the XML SAML response to include the required namespace for null elements - either in the root element or the null element itself, but I do not know the complexity of this kind of change.

ajakubo1 commented 8 months ago

Just bumping this issue. It happend in my case as well. I was casually upgrading the libs when suddenly xmlschema lib was upgraded and I started getting those errors while trying to run tests for my app:

xmlschema.exceptions.XMLSchemaKeyError: "global xs:simpleType/xs:complexType 'xs:anyType' not found"

I didn't dig into that, just wanted to let you know that there's something naughty going on.

I will pinpoint the appropriate xmlschema version as well for my app.

anenoglyadov commented 8 months ago

I have the same issue. It definitely should pin xmlschema version, as it just implicitly breaks the code for anyone who redeploy their application.

allisonmar commented 8 months ago

I also have the same issue and pinned our xmlschema version for the time being. Thanks for opening this issue!

c00kiemon5ter commented 8 months ago

hello everyone! Thank you for your report and for being patient. With v7.5.0 I have pinned xmlschema to stay on v2 for now, until we properly resolve this issue.

IdentityPython / pysaml2

xmlschema 3.0.1 broken dependency #947

Code Version

Possible Solution