Closed carterheron closed 6 months ago
From my understanding, it seems the code cannot find the certificate in order to encrypt the assertions, so for testing purposes, I modified line 229 of
flipbox\saml\core\records\traits\EntityDescriptor.php
and we were able to successfully authenticate with the Service Provider. I know this isn't a solution, but good to know that was the only thing preventing SSO. Any solution or feedback for this would be greatly appreciated.
👋 @carterheron ,
I believe you have the providers configured incorrectly. I assume you have your service provider set to encrypt assertions and you have your IdP configured without a Key Pair assigned.
Here are what these configure on the configuration pages:
Hey @dsmrt,
Thanks for getting back to me! I believe I have configured the IdP with a valid key pair and I can confirm that the SP has encrypt Assertions checked. I have attached screenshots below of the current configuration.
We have tried re-generating the key pair multiple times. Any other suggestions?
Thanks again for your response and help!
Just a heads up, when you regenerate the key, you’ll have to exchange it with the service provider as well. They need it for signature verification and decryption.
Is encryption required ? Can you test with it toggled off?
Yes, when we have re-generated keys, we have updated the configuration with the service provider. Unfortunately, encryption is required for us. When we turn it off, we do connect to the Service provider, however, the Service Provider gives us this error code HF08. Indicating that "Encrypted assertion is not found in SAML response".
@dsmrt let me know if i can provide any more information on our configuration in order to better help debug what is happening.
I patched this in 4.0.3. Can you pull that down and see how that looks?
Hey @dsmrt I just pulled and tested. Unfortunately, I still get the same result that the encryption key cannot be found. It seems the $keyDescriptorFiltered = $this->keyDescriptorsByType($keyDescriptors, $signingOrEncrypt);
always returns an empty array for me. I dumped the variables and i see keyDescriptors contains a certificate, however, when I also dump the use of the certificate it is null (which makes sense why the array is empty).
Just for clarification, in my screenshot above, i was just testing with the first object in the keyDescriptors regardless of regardless of its purpose simply to see if it would work.
To clarify, do you see your example fix https://github.com/flipboxfactory/saml-idp/issues/58#issuecomment-1858148986 in the saml-core package being pulled down? I thought you said that work for you?
If you aren't getting any key descriptor there, they aren't sending you one with the metadata which means there's something wrong on their side. Can you email me their metadata? damien at flipbox digital dot com
Sorry for the confusion, in my comment, I said "I know this isn't a solution, but good to know that was the only thing preventing SSO." The difference was in that "example fix" i bypassed the keyDescriptorsByType function just returning the first object in the input array instead of the filtered array. yes, Ill email you the metadata right now. Thanks again, for your support!
Oh ok. There's a lot here at this point and I misunderstood that point. Either way, it's a cleaner solution.
For others who might see this, we added use="encryption" to the KeyDescriptor in the metadata. Hoping this will fix things.
Yes this fixed the issue!
Awesome! Glad to hear!
Hi there,
My team and I are attempting to use this plugin to initiate SSO with another platform. We believe we have configured everything correctly, according to the docs and have toggled that the service provider wants encrypted assertions. When we use the Login Path URL to initiate SSO via IDP we receive the following error in dev mode.
For context, we are running: PHP version | 8.2.14 Craft Pro 4.5.12 Plugin version | 4.0.2
Not entirely sure how to proceed from here (or if we have simply misconfigured something) but any information or feedback would be greatly appreciated!
Thanks, CH