-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add optional setting to set a ceiling on how old a SAML response is allowed to be #577
Add optional setting to set a ceiling on how old a SAML response is allowed to be #577
Conversation
da34986
to
a8ed2ba
Compare
a8ed2ba
to
352e059
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a nice security feature to me, reasonable implemented.
The SAML spec does not appear to be involved here. Rather, this code allows the service provider to decide for itself how old of an response it will accept.
Adding this this feature would allow the window for replay attacks to be narrowed, improving security.
c3c433d
to
6405dc8
Compare
@nickiepucel Thank you for submitting this. We are trying to get things ready for a 3.x release in a few weeks and we'd like to get this code included in that. However, we need to wait for #574 to land first, which might cause some merge conflicts for you. Thank you for your understanding. |
@nickiepucel We're ready for this to land. If you'd like to resolve the merge conflicts, we'll get this in for the 3.x release. |
great! i'll try to get that done today |
@cjbarth all set! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks really good; very clean implementation. I'm concerned about possibly parsing into NaN
. I see that we don't have tests for this condition, but I believe it is possible. If I'm missing something, please let me know.
@cjbarth I took a stab at addressing the
Do you have any ideas? |
test/static/signatures/invalid/response.root-signed.assertion-signed.1advice-signed.xml
Show resolved
Hide resolved
I'll have a look later, but to unblock you, you can test locally with |
Ah I think I figured it out. I believe that because I changed the SAMLResponses' XML (by changing the Does that sound plausible? If so, do you know how how I can regenerate signatures for those SAMLResponses? |
That not only sounds plausible, that is entirely correct. The XML is cryptographically signed, and we check for that, so it is good that it failed :) You can use https://www.samltool.com/online_tools.php to re-sign XML. |
If I remember correctly that should be |
All you have to do is get any key and cert that match and use that. You're modifying the test anyway, so you can just change which cert you pass. See |
How can I sign the I tried only pasting the |
This is the code I used to create all the different test scenario's. Hope that helps, let me know if you need more info. The key.pem and cert.pem are in the location I mentioned earlier.
|
There is a "Mode" setting on that page that specifies "Assertion". Does that work? |
Unfortunately, this does not work for signing the
TYSM @vandernorth , this worked! All the tests are fixed now @cjbarth :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this; this is some very nice work. Thank you for contributing to this project. I really didn't get a chance to go over all the changed XML file carefully. I think I might pretty-print them and then check them over with a careful eye to match the name to the contents. I assume you already did that... but that is the concept of code review :)
test/static/signatures/valid/response.root-signed.assertion-signed.xml
Outdated
Show resolved
Hide resolved
@cjbarth just to clarify, there isn't any further action needed from me on this PR as of now? |
@nickiepucel You are correct. I need to buy out some time to give this a little more thurough review, but it looks good the way it is and I don't expect I'll find anything else. I might push another commit or two to pretty some XML files. I'll keep you posted. |
Summary
For security reasons, we want to ensure that there is an upper limit as to how long
a SAML response is valid for even if the IdP is configured to have extremely long (or indefinite) validity
times.
Normally an IdP would be configured to make the SAML documents short-lived, but
since in our case we run the SP and don't control the IdP, we would still like some minimal guarantees that
leaked or logged SAML documents are not dangerous after some fixed amount of time.
This change was added to the Asana fork in 2015; this PR emulates https://github.com/Asana/node-saml-lib/pull/15.
Checklist: