Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xmlschema 3.0.1 broken dependency #947

Open
christina-moore opened this issue Jan 10, 2024 · 4 comments
Open

xmlschema 3.0.1 broken dependency #947

christina-moore opened this issue Jan 10, 2024 · 4 comments

Comments

@christina-moore
Copy link

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
Copy link

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
Copy link

anenoglyadov commented Jan 17, 2024

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
Copy link

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

@c00kiemon5ter
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants