Since a tightened checking was introduced in xmldom a week ago, decryptAssertion in libsaml has been broken.
Here is the change that affects how replaceChild behaves: xmldom/xmldom@3bc6ccf
Because of this change, xml.replaceChild(assertionNode, encryptedAssertions[0]) fails with the error 'Not found: child not in parent' and an ERR_EXCEPTION_OF_ASSERTION_DECRYPTION is thrown.
This happens at least when the SAML response XML contains a header in the beginning (e.g. <?xml version="1.0" encoding="UTF-8"?>). When this is the case, entireXML contains the header as the first element, and Response as the second element, and EncryptedAssertion is a child of Response. Therefore, EncryptedAssertion is not a direct child of entireXML, and replaceChild fails due to the tightened checking.
Since a tightened checking was introduced in xmldom a week ago, decryptAssertion in libsaml has been broken.
Here is the change that affects how replaceChild behaves: xmldom/xmldom@3bc6ccf
Because of this change,
xml.replaceChild(assertionNode, encryptedAssertions[0])fails with the error 'Not found: child not in parent' and an ERR_EXCEPTION_OF_ASSERTION_DECRYPTION is thrown.This happens at least when the SAML response XML contains a header in the beginning (e.g.
<?xml version="1.0" encoding="UTF-8"?>). When this is the case, entireXML contains the header as the first element, and Response as the second element, and EncryptedAssertion is a child of Response. Therefore, EncryptedAssertion is not a direct child of entireXML, and replaceChild fails due to the tightened checking.