I’m looking at setting up an an IdP to handle SSO initiated by the SP. I was surprised at first to find that my SP’s request was unsigned as I had not yet found that signing was optional in this case. My understanding now is that the reason it’s optional is because all of the data contained by the message has (presumably) already been exchanged in an outside channel via the SP’s metadata. But that would mean in order to remain secure, since we don’t have proof the requester is who they claim to be, the metadata must be used for all other values needed from an unsigned request, right? So can you confirm that for unsigned requests, things like the AssertionConsumerServiceURL and NameIDPolicy are coming from the metadata (by way of the SAML config) and not from the request XML?
[quote]
Actually it looks like the metadata spec includes a NameIDFormat, but not NameIDPolicy, so I guess that would be open to spoofing or I'm missing something.[/quote]
As the IdP you can require that SPs sign the SAML authn request. This would be a good idea if working in a particularly sensitive environment.
Regardless, it’s primarily the SAML configuration that’s used to process the SAML authn request. If an assertion consumer service URL is included in the SAML authn request, this is checked against allowed URLs included in the configuration. The NameIDPolicy isn’t checked but instead is returned to the application which can then make any decision regarding its validity.