SAML authentication failure on undefined "identifierFormat" variable

Community Support
1

Our SAML connection to our IdP failed with an error in the logs that indicates it may be related to the “identifierFormat” variable. In app.js, if this variable is undefined, it is set to the email address using the code snippet that I took from app.js below. However, it sets it to SAML:1.1: and I think that change in the SAML protocol to SAML 1.1 in the middle of the SAML 2.0 transaction is killing our connection. That’s exactly the error that we see in the logs.

I think that the RequestedAuthnContext is set so the Comparison = “exact” combined with the undefined identifierFormat that sets the named-format to emailAddress that fails to be recognized (possibly due to the SAML 1.1 protocol setting) and the SAML connection fails.

In app.js :

 if (options.identifierFormat === undefined) {
    options.identifierFormat = 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress';
  if (this.options.identifierFormat) {
    request += `<samlp:NameIDPolicy xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protoc (and so on)
2

That line with the identifierFormat variable set to SAML:1.1: is imported from Meteor-accounts-saml in the build. It appears to have been missed when the package was updated. (That package is based on Passport SAML)

We’re using CA Siteminder as an IdP, and part of the problem is that we do have Exact match set but are using account names and login IDs different from the standard organization’s settings. I’m experimenting with that today. However, I think that if that line was fixed, a lot of the SAML provider issues may resolve, as the account ID match would be set to the email address that should be the same in both sides of the transaction. We’ll know in a couple of days when I can get some time to dink around with the code and see what changes resolve our issue.

We’re on RocketChat 2.3.1, and we’ll upgrade, but the identifierFormat issue is still present in 2.4.0 (the newest release). We are also running the whole package through a vulnerability scan. Version 2.3.1 has 8 high and quite a few medium vulnerabilities that I’ll need to patch, though this application is not visible to the outside world so our risk is a bit less.