Debugging an invalid assertion received (no audience)

[adrianovaroli]

I'm trying to debug an old project, using SAML to authenticate against an ADFS IdP. I'm stuck at receiving a saml_response that fails when generating the assertion:

$saml_response = decode_base64($saml_response);
    print STDERR "saml_response: $saml_response\n";
    my $assertion = eval {
        Net::SAML2::Protocol::Assertion->new_from_xml(
            xml => $saml_response
        ) 
    };

This fails with

Attribute (audience) does not pass the type constraint because: Must be a non-empty single line of no more than 255 chars at /usr/lib/x86_64-linux-gnu/perl5/5.32/Moose/Object.pm line 24
	Moose::Object::new('Net::SAML2::Protocol::Assertion', 'issuer', '', 'destination', '[our callback url]', 'attributes', 'HASH(0x7f11b92e3408)', 'session', '', 'nameid', '', 'audience', '', 'not_before', 'DateTime=HASH(0x7f11a410e6e8)', 'not_after', 'DateTime=HASH(0x7f11a410ea78)', 'xpath', 'XML::LibXML::XPathContext=SCALAR(0x7f11a40f58a0)', 'in_response_to', '', 'response_status', 'urn:oasis:names:tc:SAML:2.0:status:Responder') called at /usr/local/share/perl/5.32.1/Net/SAML2/Protocol/Assertion.pm line 112

Here's an example saml_response:

<samlp:Response ID="_ae896f90-5ecb-4d00-8738-91337236a165" Version="2.0"
    IssueInstant="2024-04-10T13:17:32.119Z" Destination="[our SAML callback url]"
    Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
    InResponseTo="NETSAML2_d54e304a5472d4429f20e3d44a7a224b"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://[IdP testing
        domain]/adfs/services/trust</Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <ds:Reference URI="#_ae896f90-5ecb-4d00-8738-91337236a165">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <ds:DigestValue>K4r9/0ZZqW32TG+jT9tGsKwYKwNzssSSKIo8gvWPCfo=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>[the signature value]</ds:SignatureValue>
        <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
            <ds:X509Data>
                <ds:X509Certificate>[the certificate]</ds:X509Certificate>
            </ds:X509Data>
        </KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />
    </samlp:Status>
</samlp:Response>

The library perl-net-saml2 version we're using is still 0.55 from 2022 (I've asked if we can update it), and perl is version 5.32.1. How can I best diagnose what's happening here?

[waterkip]

I don't see an Assertion node in your response. Nothing is found at the XPath level of //samlp:Response/saml:Assertion.

Based on the code of 0.55, which is a little less strict than the current code, you see that we try to instantiate the object like so:

158     my $self = $class->new(
159         issuer         => $xpath->findvalue('//saml:Assertion/saml:Issuer'),
160         destination    => $xpath->findvalue('/samlp:Response/@Destination'),
161         attributes     => $attributes,
162         session        => $xpath->findvalue('//saml:AuthnStatement/@SessionIndex'),
163         nameid         => $xpath->findvalue('//saml:Subject/saml:NameID'),
164         audience       => $xpath->findvalue('//saml:Conditions/saml:AudienceRestriction/saml:Audience'),
165         not_before     => $not_before,
166         not_after      => $not_after,
167         xpath          => $xpath,
168         in_response_to => $xpath->findvalue('//saml:Subject/saml:SubjectConfirmation/saml:SubjectConfirmationData/@InResponseTo'),
169         response_status => $xpath->findvalue('//samlp:Response/samlp:Status/samlp:StatusCode/@Value'),
170     );

The error message means you don't have an audience; nothing is found at //saml:Conditions/saml:AudienceRestriction/saml:Audience. Although the saml:Conditions seems optional in the XSD, your issuer is missing, which is required. You are also missing an Assertion[@ID] based on the current code.

I've added an assertion.xml (rename it or set the file type correctly in your editor), which shows what an assertion must have.

assertion.xml.txt

We can file a bug for not having the audience as optional; we need to investigate how/what/when, but other than that, it seems your Assertion XML isn't an Assertion.

[adrianovaroli]

Thanks for the quick reply.
To clarify: this response comes from the IdP. As far as they've told me, they see no errors in the login flow prior to this: we (the SP) start the login flow, I get redirected to the login page, enter my credentials, the 2fa, and they redirect back to me with a response like the one I pasted. I'm checking with the Ops people here if, in spite of the IdP "not seeing any errors" in the flow, our credentials are outdated or something. I guessed the flow would have failed much, much earlier, but.

[waterkip]

They are returning an error: <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" />

Even if we have a valid assertion, the user would not be able to log in.

But this thing isn't an assertion. May I ask witch which ADFS provider you are integrating?

[adrianovaroli]

I don't have at hand the specific details of their implementation. Should be a standard Microsoft ADFS implementation on their part, IIRC.

[timlegge]

Hi I have seen this with ADFS. If you look in the event log for ADFS on the server it should say what it believed was wrong with the request. It may require the removal of the encryption certificate if you created the service provider via the metadata import. The other issue is: NOTE 2: Encrypted assertions require that both the Response and Assertion be signed. Run the following command from powershell: Set-ADFS-RelyingPartyTrust -targetname [NAME OF THE RELYING PARTY TRUST] -SamlResponseSignature “MessageAndAssertion” Tim Timothy Legge ***@***.*** ***@***.***

…

On Wed, Apr 10, 2024 at 1:54 PM Wesley Schwengle ***@***.***> wrote: They are returning an error: <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" /> Even if we have a valid assertion, the user would not be able to log in. But this thing isn't an assertion. May I ask witch which ADFS provider you are integrating? — Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH3N62K62UJB3BSV5ER6MDY4VVDDAVCNFSM6AAAAABGAPFUICVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZTHE2DG> . You are receiving this because you are subscribed to this thread.Message ID: <perl-net-saml2/perl-Net-SAML2/repo-discussions/207/comments/9073943@ github.com>

[adrianovaroli]

Thank you for this reply, and thanks to @waterkip for the last, too. At this point I'm waiting on our Ops team to reply, and will get back to you.

[timlegge]

You're welcome. I am pretty sure that the ADFS logs will tell us what is wrong. Tim

…

On Wed, Apr 10, 2024, 3:45 PM Adriano Varoli Piazza < ***@***.***> wrote: Thank you for this reply, and thanks to @waterkip <https://github.com/waterkip> for the last, too. At this point I'm waiting on our Ops team to reply, and will get back to you. — Reply to this email directly, view it on GitHub <#207 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH3N62DKNPLR3J2BVLBKDTY4WCEDAVCNFSM6AAAAABGAPFUICVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TANZVGAYTM> . You are receiving this because you commented.Message ID: <perl-net-saml2/perl-Net-SAML2/repo-discussions/207/comments/9075016@ github.com>

[adrianovaroli]

Turns out the cert.pem we were using on our sp_federationmetadata.xml file was outdated, and somehow they didn't see that in their event log or error log, "everything looked fine". Updated that and the login flow worked fine.

Thank you both for helping me!

[timlegge]

Definitely a configuration issue :-) ADFS is a special IdP - I would expect it to complain somewhere in the logs though.

[waterkip]

As an FYI, we busy implementing something that deals with this kind of situation, please see #209