Skip to content
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

Loosen the validate_subject_confirmation check? #259

Closed
sthanson opened this issue Aug 18, 2015 · 6 comments
Closed

Loosen the validate_subject_confirmation check? #259

sthanson opened this issue Aug 18, 2015 · 6 comments

Comments

@sthanson
Copy link
Contributor

Currently your validate_subject_confirmation check in response.rb requires:

  1. At least one Subject > SubjectConfirmation element to have a Method of 'urn:oasis:names:tc:SAML:2.0:cm:bearer'
  2. At least one SubjectConfirmationData element to exist
  3. At least one of these three attributes (InResponseTo, NotOnOrAfter, NotBefore) to be present.
  4. All of these three attributes (InResponseTo, NotOnOrAfter, NotBefore) to be valid if present.

I was wondering what people thought of loosening this test a little bit.

The first option is to actually lower the bar the for this test. It seems like the meat of the test involves checking the InResponseTo, NotOnOrAfter, NotBefore attributes (#3 and #4 in my list above) and that #1 and #2 exist to prevent us from checking those attributes on elements where they don't exist. I would propose only failing the test if one of these three InResponseTo, NotOnOrAfter, NotBefore fails their check.... or we expected them to be there based on the structure, but they weren't actually included. But if we don't expect those attributes to be there (such as a different SubjectConfirmation Method or no SubjectConfirmationData element), then the test is simply skipped instead of failed.

I prefer this option. Aside from some important checks like the x509 certificate, I like the idea of a saml parser validating that what has been provided is valid instead of dictating every element and attribute that must be provided (because brittle structures make it harder to on board new saml partners).

The second option for loosening the test would be to add a flag to skip this test. Much like the skip_conditions option skips the validate_conditions test, a skip_subject_confirmation option would skip this test.

You can see an example of my first option in this commit:
sthanson@5bd9230

If you like this approach I'm happy to add tests and turn it into a PR.

@pitbulk
Copy link
Collaborator

pitbulk commented Aug 18, 2015

In the php-saml and the python-saml we have a "strict" parameter that relaxes the SAML validation (useful for testing environments).

I'm ok with the idea of adding a "skip_subject_confirmation" that will skip the whole process of search a valid subjectconfirmation element, adding at the top of the validate_subject_confirmation method:

return true if options[:skip_subject_confirmation]

Can you send a PR with this change and implement tests?

@sthanson
Copy link
Contributor Author

I created a new pull request with the skip_subject_confirmation flag.

#260

@pitbulk
Copy link
Collaborator

pitbulk commented Aug 18, 2015

Can you add documentation at the SAMLResponse constructor?
https://github.com/sthanson/ruby-saml/blob/skip_validate_subject_confirmation/lib/onelogin/ruby-saml/response.rb#L36

It mentions :skip_conditions and should mention :skip_subject_confirmation

Also maybe is a good moment to add those parameters to the documentation, editing README.md and adding at L143 at the "The Initialization Phase" section, explaining that some validations could be skipped during the SAMLResponse validation, and provide an example.

@sthanson
Copy link
Contributor Author

Hi @pitbulk

I added documentation to the two files you suggested.

I added the new README.md documentation at L169 instead of L143 because it seemed like that "def saml_settings" code block related to the previous paragraphs and it seemed out of place after my new paragraph. Hope that is ok. If not, I'm happy to move it to L143 like you originally suggested.

I also noticed I had put the wrong units in a previous comment I committed to the app. "allowed_clock_drift" is in seconds, not minutes. So I updated the comments to reflect that. I can re-make my pull request without this change if you prefer.

Thanks!

@sthanson
Copy link
Contributor Author

I made the text change and I'm rebuilding the PR to get rid of the merge commit.

@sthanson
Copy link
Contributor Author

Rebuilt PR to get rid of my merge commit:

#261

@pitbulk pitbulk closed this as completed Aug 28, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants