Open jkamenik opened 10 years ago
@jkamenik, can you tell where the validation is failing at all? Also, which version of the ruby-saml gem are you using? My github copy is probably very far behind the official version. My patch wasn't accepted to the official project because too much had changed by the time I did a pull request. And it was a pain in the ass to try and manually change everything to merge.
If you're still using my ruby-saml gem, you might be able to try skipping the signature validation. See line 96 in ruby-saml/lib/onelogin/saml/response.rb. In the rails saml_controller.rb, line 30, you might be able to get away with:
@response = Onelogin::Saml::Response.new(params[:SAMLResponse], :skip_validation => true)
Of course, that doesn't really solve the problem, but it might get you closer. I didn't really touch XML X.509 signature validations because I couldn't find a really good XML parser for ruby.
I actually can't explain why validate!
would fail and then is_valid?
would be true except that it appears that XMLSecurity is slightly destructive.
Digging deeper by creating my own SP (https://github.com/WaterfallFMS/saml_client) I think the issue was Canonix. Nokogiri now includes canonical support. But it canonicalizes the XML without moving attributes around (which I think is the correct behavior), while Canonix does.
Your project worked against the sample IdP (https://github.com/drnic/ruby-saml-idp-rails3-example) because of a coincidence. The sample IdP uses the 'ruby-saml-ip' gem, which does simple string interpolation into a handcrafted XML document. It was handcrafted to match the Canonix canonical form already.
My IdP was based on the 'saml_idp' gem which uses an XML builder to generate the XML and Nokigri to canonicalize it for the signature. So canonical form did not match and therefore the .
I am using the https://github.com/sportngin/saml_idp gem as a basis for a IdP I am creating. No matter what I try I always end up on fail
Saml#fail
.The last
true
, which is caused by@response.validatate!
. So@response.is_valid?
returnsfalse
causing the fail view, but when re-validated it works, even though internally they call the same code.Here is the parsed response that was placed in the log.