We’ve recently downloaded the trial and we’re trying to get the Shibboleth demo working (we as the SP and Shibboleth as the IP) before proceeding with testing in our application. We’ve followed the directions in the developer guide but are getting this error in the Shibboleth log:
15:10:58.159 - ERROR [org.opensaml.xml.security.SigningUtil:250] - Error during signature verificationjava.security.SignatureException: Signature length not correct: got 256 but was expecting 128
We’ve done the following:
Using the ComponentSpaceMetadata.xml sample we changed entityID to be unique to us and uploaded it to testshib
Modified the ServiceProvider tag in saml.config to point to the entityID above
Changed the PartnerIdP key in the web.config to use the testshib PartnerIdentityProvider
Aside from this we’ve left everything else the same. Are we missing a step somewhere?Thanks!
We recently changed to 2048 bit SHA-256 signed test certificates. It may be related to these certificates. If you search for this error you’ll see it mentioned in the Shibboleth forum but apparently there’s a fix to Shibboleth for this. We’ll do some testing here as well but in the meantime you might want to try with your own certificates.
The error indicates that Shibboleth doesn’t have http://localhost:51481/SAML/AssertionConsumerService configured as an assertion consumer service for your service provider. Could you please double check the SAML metadata at the Shibboleth site and confirm that this is the correct URL? The entries you supplied below match up (ie both specify http://localhost:51481/SAML/AssertionConsumerService) but the error from Shibboleth indicates they’re different.
Thanks for the reply. Yes, I’ve checked again and again and as far as I can tell, I’ve set everything up correctly. Since I wasn’t able to get the sample app set up, I’m not sure if it’s something I’m doing, something on testshib or something in the library. I’ve attached my metadata and saml.config files.
Based on the log, it looks like it’s sending the correct URL
Thanks for the metadata and configuration. These both look correct. One small discrepancy I see is that in the original Shibboleth error message it refers to http://www.cyf.com. Your metadata and configuration use http://www.cyfeon.com instead. I assume you changed this since the original error but thought I should mention it just in case. Also, I wasn't able to find your metadata at: http://www.testshib.org/metadata/testshib-two-metadata.xml Should it still be there or have you since removed it?
As for the name diff, yes, I just changed the name in my posts to something more generic than what was in my metadata. The one in the metadata is what we’ve been testing with.
By the way, really appreciate the responsive support and help figuring this out!
I think you’re right about the Shibboleth metadata being stored elsewhere. I followed the instructions in our Developer Guide and was able to successfully SSO from the ExampleServiceProvider to the TestShib IdP. This included using the sp.cer certificate that we ship. I didn’t have any issues with the certificate and SSO completed successfully. As an experiment, please deploy our unmodified ExampleServiceProvider to your localhost IIS. Update the saml.config to specify https://test.componentspace.com as the service provider name. The rest of the configuration shouldn’t need to be changed.
Then, browse to http://localhost/ExampleServiceProvider and attempt SSO to Shibboleth. This is using the metadata I uploaded to Shibboleth so it should all work on your system too. Once we get this working on your system we can then compare metadata etc.
I apologize in advance for my broken English, I will try my best to make myself “understandable”.
We are also currently testing ComponentSpace against TestShib Idp and we are facing the same problem mentioned in the initial post. Here is an excerpt from TestShib’s log:
[quote]
12:11:12.858 - ERROR [org.opensaml.xml.security.SigningUtil:250] - Error during signature verificationjava.security.SignatureException: Signature length not correct: got 256 but was expecting 128at sun.security.rsa.RSASignature.engineVerify(RSASignature.java:189) ~[na:1.7.0_55]at java.security.Signature$Delegate.engineVerify(Signature.java:1172) ~[na:1.7.0_55]at java.security.Signature.verify(Signature.java:623) ~[na:1.7.0_55]at org.opensaml.xml.security.SigningUtil.verify(SigningUtil.java:248) [xmltooling-1.4.0.jar:na]at org.opensaml.xml.security.SigningUtil.verify(SigningUtil.java:216) [xmltooling-1.4.0.jar:na]at org.opensaml.xml.security.SigningUtil.verifyWithURI(SigningUtil.java:185) [xmltooling-1.4.0.jar:na]at org.opensaml.xml.signature.impl.ExplicitKeySignatureTrustEngine.validate(ExplicitKeySignatureTrustEngine.java:163) [xmltooling-1.4.0.jar:na]at org.opensaml.xml.signature.impl.ChainingSignatureTrustEngine.validate(ChainingSignatureTrustEngine.java:80) [xmltooling-1.4.0.jar:na]
[/quote]
In one of your official reply, you mentioned being able to configure an SP by following the directions in the ComponentSpace documentation while using the provided sp.cer as is. Since that post is over a year old, I was wondering if the problem was on the SP or Idp dependant?
I am in the process of creating a 1024 bit SHA-256 certificate to further our testing of ComponentSpace implementation but I was wondering what the implications were?
The goal of this operation is to allow our SP to join 2 different shib federations (partners if you will, the both Idps are not managed by our organisation). In that case, should the Idp «decide» on key length and we as SP, conform to the Idp specs or should we as a SP, decide on key length and force the Idp to conform to our specs?
Hi Phil The original poster appeared to get around this issue, presumably by using a different certificate. When we tried to reproduce the issue using our 2048 bit SHA-256 signed test certificate (SP.cer), we didn’t have any issues. I assume there’s some sort of limitation regarding certificates on the Shibboleth test site. However, we were never able to reproduce the issue and I’m not sure exactly what the original poster did to get around the certificate problem. We use the .NET framework’s X509Certificate2 class to load certificates and I’m not aware of any restrictions on key lengths etc. You will have to work with the partner IdPs to see if they have any restrictions. From our experience this generally isn’t an issue. We’ve only ever heard it mentioned about Shibboleth and, as I said, we weren’t able to reproduce the issue. As an experiment, could you replace your certificate with the SP.pfx/SP.cer certificate and private key that we ship and see if you still have the same issue? It would be interesting to know what differences there are between your certificate and our test SP.cer.
as I mentioned in my previous post, I continued testing with different certificate. I was able to fix the problem with a self signed 1028 bit certificate. I did further testing with a self signed 2048 bit certificate and I managed to make it work. Upon further inspection, it turns out that the problem was in the metadata file. The base 64 certificate in the template metadata packaged with the demo does not match the sp.cer (or pfx) that comes with the demo. Updating the metadata with appropriate info from provided .cer fixed the problem aswell.
For posterity, to anyone trying the demo out, when tweaking the metadata before uploading to TestShib, beside tweaking the id and urls, it is mandatory to update the base64 certificate blob with the content from sp.cer. That will fix the issue without needing to generate a self-signed certificate for testing purpose.
Now that I have this issue fixed, another issue arose, maybe I can get a little help on that. I now have this error on the SP side after logging in on the Idp
[quote]
[CryptographicException: SignatureDescription could not be created for the signature algorithm supplied.] System.Security.Cryptography.Xml.SignedXml.CheckSignedInfo(AsymmetricAlgorithm key) +131386 System.Security.Cryptography.Xml.SignedXml.CheckSignature(AsymmetricAlgorithm key) +34 System.Security.Cryptography.Xml.SignedXml.CheckSignatureReturningKey(AsymmetricAlgorithm& signingKey) +74 ComponentSpace.SAML2.Utility.XmlSignature.Verify(XmlElement xmlElement, AsymmetricAlgorithm signingKey, SignedXml signedXml)
[/quote]
I have read on the net that the problem is an issue with SHA-256 not being enabled properly. I have read on this same forum that there is a fix for this but only 2 solutions were listed, one for .NET Framwork 4.5 and the other one, for a .NET 3.5 Framework security extension that needs to be added to the GAC and then, configured in the machine.config.
Unfortunately, for this particular SP, we are still stuck with .NET Framework 2.0 and this is the main reason we chose ComponentSpace (with it’s ,NET 2.0 compatibility) over WIF which is restricted to.NET 3.5 and above. I believe we could resolve this issue by using SHA-1 instead of SHA-256 but if I understand correctly, SHA-1 has been deprecated due to collision issue and should be avoided, please correct me if I am wrong. Is there a way to «enable» SHA-256 signing on a server with .NET 2.0 only?
Thanks for pointing out the metadata issue. Regarding SHA-256 support, the only options are as you mentioned. The .NET framework v2.0 does not support SHA-256 XML signatures. My understanding is that SHA-1 has not been compromised yet but it’s only a matter of time. For the next few years it’s probably still ok. The following article makes some predictions around this. https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
I am struggling with almost same sort of error as discussed in previous posts. When I am trying to access my service provider url i.e. "<a href=“http://localhost/ExampleSarbServiceProvider/login.aspx",">http://localhost/ExampleSarbServiceProvider/login.aspx”, some times I am automatically redirect to error page and some times idp login page. After giving details (eg. myself/myself) on idp login, I am again redirect to error page. While checking log I am getting following information:
04:33:38.347 - DEBUG [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:366] - Decoding message with decoder binding 'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect’04:33:38.349 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:128] - Looking up relying party configuration for http://localhost/ExampleSarbServiceProvider/04:33:38.349 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:134] - No custom relying party configuration found for http://localhost/ExampleSarbServiceProvider/, looking up configuration based on metadata groups.04:33:38.350 - DEBUG [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:157] - No custom or group-based relying party configuration found for http://localhost/ExampleSarbServiceProvider/. Using default relying party configuration.04:33:38.350 - WARN [org.opensaml.common.binding.security.IssueInstantRule:102] - Message was not yet valid: message time was 2015-07-15T08:38:46.915Z, latest valid is: 2015-07-15T04:38:38.350-04:0004:33:38.351 - WARN [edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:406] - Message did not meet security requirementsorg.opensaml.ws.security.SecurityPolicyException: Message was rejected because was issued in the future at org.opensaml.common.binding.security.IssueInstantRule.evaluate(IssueInstantRule.java:103) ~[opensaml-2.6.0.jar:na] at org.opensaml.ws.security.provider.BasicSecurityPolicy.evaluate(BasicSecurityPolicy.java:51) ~[openws-1.5.0.jar:na] at org.opensaml.ws.message.decoder.BaseMessageDecoder.processSecurityPolicy(BaseMessageDecoder.java:132) ~[openws-1.5.0.jar:na] at org.opensaml.ws.message.decoder.BaseMessageDecoder.decode(BaseMessageDecoder.java:83) ~[openws-1.5.0.jar:na] at org.opensaml.saml2.binding.decoding.BaseSAML2MessageDecoder.decode(BaseSAML2MessageDecoder.java:70) ~[opensaml-2.6.0.jar:na] at edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler.decodeRequest(SSOProfileHandler.java:386) [shibboleth-identityprovider-2.4.0.jar:na] Please help me to find what thing I am doing wrong as I am following same pattern given in developer guide.
The Shibboleth log includes the following entries. "Looking up relying party configuration for http://localhost/ExampleSarbServiceProvider/" "No custom relying party configuration found for http://localhost/ExampleSarbServiceProvider/" What this means is that a relying party (aka partner service provider) hasn't been configured in the Shibboleth IdP with an entityID of "http://localhost/ExampleSarbServiceProvider/". Your service provider is sending a SAML authn request to Shibboleth with an issuer value set to http://localhost/ExampleSarbServiceProvider/. Shibboleth will then use this to lookup its configuration to find the corresponding relying party. The message indicates it hasn't been configured or a different name was used. Shibboleth then attempts to use a default configuration entry. You should ensure that a relying party is configured in Shibboleth with an entityID of "http://localhost/ExampleSarbServiceProvider/". Also, it's probably a good idea to not use localhost as part of this URL. The entityID URL should be unique but it doesn't have to point to an actual web page etc. The Shibboleth log also includes: "Message was not yet valid: message time was 2015-07-15T08:38:46.915Z, latest valid is: 2015-07-15T04:38:38.350-04:0004:33:38.351". You need to ensure the clocks are synchronized. The clock at the SP appears to be 4 minutes ahead of the Shibboleth clock. Make sure to set your clock using an NTP server etc so it's synchronized with the Shibboleth server.
As per your answer there is some problem of configuration on shibboleth which I have done by using my metadata. But I am still not able to configure where is the problem.I am sending my metadata for reference(as attached) if you can help on this.
Moreover I have started using my subdomain as an entityID so that it becomes unique. Now error is coming : “Error Message: No peer endpoint available to which to send SAML response”
log Error is :
06:54:29.212 - WARN [org.opensaml.saml2.binding.AuthnResponseEndpointSelector:206] - Relying party ‘http://clareitydev.geodatadirect.com/’ requested the response to be returned to endpoint with ACS URL ‘http://clareitydev.geodatadirect.com/AssertionConsumerService.aspx’ and binding ‘urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST’ however no endpoint, with that URL and using a supported binding, can be found in the relying party’s metadata 06:54:29.212 - ERROR [edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:447] - No return endpoint available for relying party http://clareitydev.geodatadirect.com/ As per time issue I didn’t understand why it is that happening.
Even I have tried with componentspace attached certificate that provided with trial version, but no luck…Quite frustrated after spending so much time on this…ah, Please help!