Closed benjaminkohl closed 4 years ago
Adding that field shouldn’t have anything to do with verifying the signature unless something changed on the idp side which reissued a new cert. Can you check to see if the key or cert has changed on your sp provider (in craft) and their AD metadata compared to what you have in craft. If you can get an updated version of the metadata that might be good. Also, check to see if their metadata has more than one signing key.
If you need to get login working for the time being, you can comment out the following block from: vendor/flipboxfactory/saml-core/src/validators/Assertion.php:74
while you debug the issue.
if ($key = $this->identityProvider->signingXMLSecurityKey()) {
$this->validators[] = new SignedElement($key);
}
At this point, I'm wondering whether the IdP metadata/cert has changed OR if there's multiple signing keys in the metadata. If there are multiple signing keys I may have to put a patch in for that.
Let me know what you find.
Ok, I have requested that they send me the metadata again. Looking at the current metadata XML, it appears there are three different signing keys (unless I am misinterpreting what I am seeing). But it looks like they each show up a few times in the XML in different places. I don't know much about this stuff so maybe I can send this XML to you securely somehow?
Sure thing. Send me a note here and we can start an email thread: https://www.flipboxdigital.com/contact
If you can grab the "Response" message from the logs or the request, that'd be helpful as well.
Ok, I sent both.
We identified the issue as stemming from multiple signing
certs connected to the IdP metadata. I now loop through all of them and test each one.
Run an update on the saml-core (should update to 2.0.25) lib and let me know how that works out.
composer update flipboxfactory/saml-core
I updated the plugin and the login process has resumed working as expected. Thank you for the quick fix!
Unfortunately, this exception has returned to our SSO implementation during a time when nobody was making changes to the site. We were running version 2.0.10 of the plugin but I decided to update to 2.0.14 this morning to see if that would correct the issue and it did not. Here is the latest version of the stack trace:
2020-01-02 11:46:04 [-][-][32abbd468240107c10366fb5cbd6d4ee][error][Exception] Exception: Unable to validate Signature in /home/site/prod/vendor/simplesamlphp/saml2/src/SAML2/Utils.php:181
Stack trace:
#0 /home/site/prod/vendor/simplesamlphp/saml2/src/SAML2/Assertion.php(672): SAML2\Utils::validateSignature(Array, Object(RobRichards\XMLSecLibs\XMLSecurityKey))
#1 /home/site/prod/vendor/flipboxfactory/saml-core/src/validators/SignedElement.php(34): SAML2\Assertion->validate(Object(RobRichards\XMLSecLibs\XMLSecurityKey))
#2 /home/site/prod/vendor/flipboxfactory/saml-core/src/validators/Assertion.php(107): flipbox\saml\core\validators\SignedElement->validate(Object(SAML2\Assertion), Object(SAML2\Assertion\Validation\Result))
#3 /home/site/prod/vendor/flipboxfactory/saml-core/src/validators/Response.php(94): flipbox\saml\core\validators\Assertion->validate(Object(SAML2\Assertion))
#4 /home/site/prod/vendor/flipboxfactory/saml-core/src/validators/Response.php(74): flipbox\saml\core\validators\Response->validateAssertions(Object(SAML2\Response), Object(SAML2\Response\Validation\Result))
#5 /home/site/prod/vendor/flipboxfactory/saml-sp/src/controllers/LoginController.php(80): flipbox\saml\core\validators\Response->validate(Object(SAML2\Response))
#6 [internal function]: flipbox\saml\sp\controllers\LoginController->actionIndex()
#7 /home/site/prod/vendor/yiisoft/yii2/base/InlineAction.php(57): call_user_func_array(Array, Array)
#8 /home/site/prod/vendor/yiisoft/yii2/base/Controller.php(157): yii\base\InlineAction->runWithParams(Array)
#9 /home/site/prod/vendor/craftcms/cms/src/web/Controller.php(187): yii\base\Controller->runAction('', Array)
#10 /home/site/prod/vendor/yiisoft/yii2/base/Module.php(528): craft\web\Controller->runAction('', Array)
#11 /home/site/prod/vendor/craftcms/cms/src/web/Application.php(299): yii\base\Module->runAction('saml-sp/login', Array)
#12 /home/site/prod/vendor/yiisoft/yii2/web/Application.php(103): craft\web\Application->runAction('saml-sp/login', Array)
#13 /home/site/prod/vendor/craftcms/cms/src/web/Application.php(284): yii\web\Application->handleRequest(Object(craft\web\Request))
#14 /home/site/prod/vendor/yiisoft/yii2/base/Application.php(386): craft\web\Application->handleRequest(Object(craft\web\Request))
#15 /home/site/prod/public/index.php(26): yii\base\Application->run()
#16 {main}
I still have your email ... I'll email you.
After exchanging some info with @benjaminkohl, seems like the certs changed on the IdP side of things. I added a ticket to handle importing the metadata via URL to ease imports of the metadata when stuff like this happens.
@benjaminkohl Please elaborate as needed here. I'll close this out for now.
One thought I have is that if the metadata does get cached, maybe there can be certain situations that force it to refresh automatically. I'm just worried something like this may happen again where the metadata gets refreshed at the IDP and nobody is around to update it so people can't access the site.
@benjaminkohl I copied your comment over to the new issue https://github.com/flipboxfactory/saml-sp/issues/47
Plugin version: 2.0.9 Craft version: 3.3.13
Yesterday morning, our client's site with the Azure AD SSO was working as usual. I went into the identity provider settings and added one more attribute mapping for a thumbnail_photo. I re-saved the IDP settings and now the login process fails on each attempt.
Using my same test credentials provided by the client, I was able to log in to one of their other web services. I also checked with our own team and nobody else made any changes to the site (no Craft/plugin updates). Did something get messed up when I added the new attribute mapping? I have since removed it but I still get the same error. Here is the stack trace that I see now: