Allow raw (unsigned) assertions

[rordeix]

According to SAML specifications assertions may be signed.

This PR allows to add raw assertions on responses.
I branched from signed_response_message which has an updated README about signing responses and assertions

[Zogoo]

According to SAML specifications assertions may be signed.

This PR allows to add raw assertions on responses.
I branched from signed_response_message which has an updated README about signing responses and assertions

Thanks for your contribution, I like to have an optional config for Assertion signature. But, I just wonder that is there any use case for non signed assertion, because for security reason assertion or response must be signed right?
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

[rordeix]

According to SAML specifications assertions may be signed.
This PR allows to add raw assertions on responses.
I branched from signed_response_message which has an updated README about signing responses and assertions

Thanks for your contribution, I like to have an optional config for Assertion signature. But, I just wonder that is there any use case for non signed assertion, because for security reason assertion or response must be signed right?
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

I agree with you, for security reasons assertions should be signed.
In our case we have an idp initiated flow to a server which requires the responses the to be signed but does not support signed assertions.
I thought someone else could face same problem (it could be fixed on the other side too, if they add support for signed assertions). Perhaps is a really particular case and does not add much value to anyone else?

[Zogoo]

According to SAML specifications assertions may be signed.
This PR allows to add raw assertions on responses.
I branched from signed_response_message which has an updated README about signing responses and assertions

Thanks for your contribution, I like to have an optional config for Assertion signature. But, I just wonder that is there any use case for non signed assertion, because for security reason assertion or response must be signed right?
https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

I agree with you, for security reasons assertions should be signed.
In our case we have an idp initiated flow to a server which requires the responses the to be signed but does not support signed assertions.
I thought someone else could face same problem (it could be fixed on the other side too, if they add support for signed assertions). Perhaps is a really particular case and does not add much value to anyone else?

Actually, I was missing that if response itself get signed by "IdP", assertion could be as raw. It won't bring critical security issue.
And it might be good that print warning if someone mistakenly allows unsigned response with unsigned assertion.
About as merge request if you are not rushing, can I wait for some other guys also give some review of your idea?

[rordeix]

I addressed your comments. I'm not sure about the controller test, please take a look and any feedback is welcome.
About the merge request, there is no rush, we are using our own fork in the meantime. When this gets merged we will update our gemfile.
One unrelated question to this PR, if I can ask: is saml-idp#88 is merged on this repo?

[Zogoo]

I addressed your comments. I'm not sure about the controller test, please take a look and any feedback is welcome.
About the merge request, there is no rush, we are using our own fork in the meantime. When this gets merged we will update our gemfile.
One unrelated question to this PR, if I can ask: is saml-idp#88 is merged on this repo?

I'm not merged yet. I have solved the issue with lambda which return what I wanted to return. I could achieve that which overrides SAML IdP config before generate response.
But, I just created a new pull request for saml_idp#88 in my repo and checking how will affect to an existing project.
BTW, I just thought that we can communicate each other on Gitter and I have recently created room. If you want to join, here is the link https://gitter.im/saml_idp

[rordeix]

I addressed your comments. I'm not sure about the controller test, please take a look and any feedback is welcome.
About the merge request, there is no rush, we are using our own fork in the meantime. When this gets merged we will update our gemfile.
One unrelated question to this PR, if I can ask: is saml-idp#88 is merged on this repo?

I'm not merged yet. I have solved the issue with lambda which return what I wanted to return. I could achieve that which overrides SAML IdP config before generate response.
But, I just created a new pull request for saml_idp#88 in my repo and checking how will affect to an existing project.
BTW, I just thought that we can communicate each other on Gitter and I have recently created room. If you want to join, here is the link https://gitter.im/saml_idp

Thank you, Zogoo! For your answers and the invitation, I will join the Gitter room

[Zogoo]

@rordeix my all pull requests are merged into original repo, if you create your pull request in original repo, probably other guys also take look at it and we might can easily merge it.