Skip to content

xmlschema 3.0.1 broken dependency #947

@christina-moore

Description

@christina-moore

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions