Skip Menu |
 

This queue is for tickets about the Net-SAML2 CPAN distribution.

Report information
The Basics
Id: 77194
Status: open
Priority: 0/
Queue: Net-SAML2

People
Owner: TIMLEGGE [...] cpan.org
Requestors: jchang [...] athenahealth.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: CA and Signature verification should not be required
Date: Mon, 14 May 2012 12:36:11 -0400
To: "bug-Net-SAML2 [...] rt.cpan.org" <bug-Net-SAML2 [...] rt.cpan.org>
From: Jason Chang <jchang [...] athenahealth.com>
Download (untitled) / with headers
text/plain 1.8k
Under Net::SAML2 0.17, the POST and Redirect binding modules require the certificate for the certificate authority that issued the IdP certificate; and they sign the request before sending it to the identity provider, and assume that the resulting assertion has been signed. However this verification is optional under the SAML 2 specification. (In the Core specification with errata inline at http://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf, lines 3033 and 3036 indicate "All SAML assertions MAY be signed using XML signature." and "All SAML protocol request and response messages MAY be signed using XML signature.".) Thus these modules cannot be used in a standards-compliant way with some identity providers. For example, OneLogin does not use XML signature by default. Assertions from them without signatures cause an instantiation error. I suggest the following changes: Make cacert an optional parameter in POST and Redirect. Make key an optional parameter in Redirect. In POST::handle_response, do not call $x->verify unless a Signature element is present. In POST::handle_response, do not instantiate a VerifyX509 from $self->cacert nor call $ca->verify($cert) unless $self->cacert is defined. In POST::handle_response, do not append " (verified)" to the subject if verification was not attempted. Add new functions in Redirect that are modified versions of sign and verify (leaving sign and verify alone, since it would be confusing to have a function named "sign" that could optionally not sign); for example, "generate_uri" and "handle_response". The new Redirect::generate_uri would add the SigAlg and Signature params, and would call new_private_key and would calculate $sig, only if $self->key is defined. The new Redirect::handle_response would instantiate $cert and $rsa_pub, and would check the SigAlg and Signature params, only if Signature is present.
Subject: Re: [rt.cpan.org #77194] CA and Signature verification should not be required
Date: Tue, 15 May 2012 19:51:21 +0100
To: bug-Net-SAML2 [...] rt.cpan.org
From: Chris Andrews <chris [...] nodnol.org>
Download (untitled) / with headers
text/plain 1.5k
On Mon, May 14, 2012 at 5:36 PM, Jason Chang via RT <bug-Net-SAML2@rt.cpan.org> wrote: Show quoted text
> Under Net::SAML2 0.17, the POST and Redirect binding modules require the certificate for the certificate authority that issued the IdP certificate; and they sign the request before sending it to the identity provider, and assume that the resulting assertion has been signed. > > However this verification is optional under the SAML 2 specification. (In the Core specification with errata inline at http://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf, lines 3033 and 3036 indicate "All SAML assertions MAY be signed using XML signature." and "All SAML protocol request and response messages MAY be signed using XML signature.".) > > Thus these modules cannot be used in a standards-compliant way with some identity providers. For example, OneLogin does not use XML signature by default. Assertions from them without signatures cause an instantiation error.
You're absolutely right that this module doesn't implement the full SAML 2.0 specification, and it also hardcodes a number of assumptions that were true for my original use of SAML. I'd happily accept patches that make what's there already useful in more situations. I've got a specific question about the situation you describe though: if you're not signing the assertions, what do you do to verify their origin? Is this something that's only applicable to the Artifact binding, where you can be sure of the IdP's identity in other ways? Thanks, Chris.
Subject: RE: [rt.cpan.org #77194] CA and Signature verification should not be required
Date: Tue, 15 May 2012 15:35:56 -0400
To: "bug-Net-SAML2 [...] rt.cpan.org" <bug-Net-SAML2 [...] rt.cpan.org>
From: Jason Chang <jchang [...] athenahealth.com>
Download (untitled) / with headers
text/plain 2.3k
Hi Chris, Thanks for the reply! I'll put a patch together; how should I go about submitting it? (Format, input method, etc.) As to your other question, I admit best practices in fact argue against forgoing signatures in this way, and in the end we may in fact not allow integration with any identity provider that does not sign its assertions. But we nonetheless want to keep enforcement of best practices distinct from technical compliance with standards to enable correct assignment of responsibility. Thanks again! Jason Show quoted text
-----Original Message----- From: Chris Andrews via RT [mailto:bug-Net-SAML2@rt.cpan.org] Sent: Tuesday, May 15, 2012 2:52 PM To: Jason Chang Subject: Re: [rt.cpan.org #77194] CA and Signature verification should not be required <URL: https://rt.cpan.org/Ticket/Display.html?id=77194 > On Mon, May 14, 2012 at 5:36 PM, Jason Chang via RT <bug-Net-SAML2@rt.cpan.org> wrote:
> Under Net::SAML2 0.17, the POST and Redirect binding modules require the certificate for the certificate authority that issued the IdP certificate; and they sign the request before sending it to the identity provider, and assume that the resulting assertion has been signed. > > However this verification is optional under the SAML 2 specification. (In the Core specification with errata inline at http://www.oasis-open.org/committees/download.php/35711/sstc-saml-core-errata-2.0-wd-06-diff.pdf, lines 3033 and 3036 indicate "All SAML assertions MAY be signed using XML signature." and "All SAML protocol request and response messages MAY be signed using XML signature.".) > > Thus these modules cannot be used in a standards-compliant way with some identity providers. For example, OneLogin does not use XML signature by default. Assertions from them without signatures cause an instantiation error.
You're absolutely right that this module doesn't implement the full SAML 2.0 specification, and it also hardcodes a number of assumptions that were true for my original use of SAML. I'd happily accept patches that make what's there already useful in more situations. I've got a specific question about the situation you describe though: if you're not signing the assertions, what do you do to verify their origin? Is this something that's only applicable to the Artifact binding, where you can be sure of the IdP's identity in other ways? Thanks, Chris.
Subject: Re: [rt.cpan.org #77194] CA and Signature verification should not be required
Date: Wed, 16 May 2012 09:52:03 +0100
To: bug-Net-SAML2 [...] rt.cpan.org
From: Chris Andrews <chris [...] nodnol.org>
Download (untitled) / with headers
text/plain 935b
On Tue, May 15, 2012 at 8:36 PM, Jason Chang via RT <bug-Net-SAML2@rt.cpan.org> wrote: ... Show quoted text
> Thanks for the reply! I'll put a patch together; how should I go about submitting it? (Format, input method, etc.)
Ideally a github fork, but if you're not already using it an emailed unidiff is just fine. Show quoted text
> As to your other question, I admit best practices in fact argue against forgoing signatures in this way, and in the end we may in fact not allow integration with any identity provider that does not sign its assertions. But we nonetheless want to keep enforcement of best practices distinct from technical compliance with standards to enable correct assignment of responsibility.
I see where you're coming from, but I do feel that signature validation should at least be something you need to explicitly disable - otherwise it may be too easy to arrive at a "working" but completely insecure system without any validation. Chris.
Download (untitled) / with headers
text/plain 451b
Show quoted text
> I see where you're coming from, but I do feel that signature > validation should at least be something you need to explicitly disable > - otherwise it may be too easy to arrive at a "working" but completely > insecure system without any validation.
I agree with Chris but I will take a look at onelogin's Idp to see if I can test against something without a default of signed. Will not be in the next release but yu've been waiting 8 years so,...
Download (untitled) / with headers
text/plain 714b
On Tue Apr 07 22:25:34 2020, TIMLEGGE wrote: Show quoted text
> > I agree with Chris but I will take a look at onelogin's Idp to see if > I can test against something without a default of signed. > > Will not be in the next release but yu've been waiting 8 years so,...
I took a look at the onelogin IdP and one big issue is related to their use of self-signed certificates. Net::SAML2 uses the trust store of openssl and the underlying server to trust the signature. That is not easy to trust with the current implementation since it needs the user to understand how to trust that certificate gets trusted A certificate fingerprint might help with that but I have not yet sen any indication that they don't sigh assertions


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.