TypeError when parsing login response

[sbai]

I'm experiencing an issue on samlify 2.7.6 that is similar to the situation discussed in a previous issue (#222). We are using samlify as an SP, and parsing a login response from a customer's IDP. The error is nearly identical:

TypeError: Cannot read property 'map' of null
    at /app/node_modules/samlify/src/libsaml.ts:369:37
    at Array.forEach (<anonymous>)
    at Object.verifySignature (/app/node_modules/samlify/src/libsaml.ts:345:13)
    at /app/node_modules/samlify/src/flow.ts:181:55
    at step (/app/node_modules/samlify/build/src/flow.js:33:23)
    at Object.next (/app/node_modules/samlify/build/src/flow.js:14:53)
    at fulfilled (/app/node_modules/samlify/build/src/flow.js:5:58)
    at propagateAslWrapper (/app/node_modules/async-listener/index.js:504:23)
    at /app/node_modules/async-listener/glue.js:188:31
    at /app/node_modules/async-listener/index.js:541:70
    at /app/node_modules/async-listener/glue.js:188:31
    at <anonymous>

The customer's IDP metadata has two certs, neither of which specify use=:

    <KeyDescriptor>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>
            cert1
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>
    <KeyDescriptor>
      <ds:KeyInfo>
        <ds:X509Data>
          <ds:X509Certificate>
            cert2
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </KeyDescriptor>

The login response from the customer has signed, but not encrypted, assertions.

It seems that the logic in samlify for identifying shared certificates gets confused when there's more than one of them, and ends up returning neither of them. Removing one of the two certs from the IDP metadata causes the login response to be parsed correctly, since it appears the customer is only using the other one currently. We are verifying with the customer how they actually use each cert, but in the meantime this looks like a bug in samlify.

Incidentally, I think #397 is a good idea, since the current error is not very useful.