Require `signing_keypair` on IdP create

[david-crespo]

Current these two fields are optional. I talked to @jmpesp and we decided they shouldn’t be.

[jmpesp]

Clarification: I was referring to the IDP's signing keys, not the SP (aka our) signing keys. Our signing key can remain optional.

[david-crespo]

Ok, I see now I didn't understand when we were chatting about it. What I was referring to as the IdP is the IdP model in our DB, which you are calling the SP because it governs what we (the SP) do when we get a request from the actual external IdP.

In that case I share Luqman's question: what is the relationship between the signing_keypair that come in on the IdP create request body and the keys that come in on the response from the metadata source? Is it that our signing_keypair is used to sign our requests/responses to them, and the signing key we get in the metadata is just a public key we can use to verify the signature on requests/responses from them? So they're unrelated in that you can have both or neither or one or the other and it all can theoretically work fine?

[jmpesp]

Is it that our signing_keypair is used to sign our requests/responses to them, and the signing key we get in the metadata is just a public key we can use to verify the signature on requests/responses from them?

This is exactly it, sorry for the term overload. In the SAML sense, the SP can sign the request, and the IDP can sign the response. The linked PR changes Nexus to require that the IDP's metadata document have a public key we can use to verify the response/assertion, and our existing code already requires that a signature exists (this is codified in test_reject_unsigned_saml_response).

The signing_keypair is used to sign our requests to the IDP. It's a configurable option whether or not an IDP can require this (and reject unsigned requests).

So they're unrelated in that you can have both or neither or one or the other and it all can theoretically work fine?

The whole flow will work either way, yeah, it's just that accepting unsigned assertions is insecure :)