UnverifiedRelyingParty

[Eric Hattemer]

If we were to enable the SAML2.SSO profile only, and force the use of
the consent flow for the UnverifiedRelyingParty relying-party
configuration, are there significant security considerations in not
having metadata for those parties?  The SP's would still download the
IdP metadata, and we'd sign responses, but not expect requests to be signed.

I get that this would allow someone to impersonate an SP if all they did
was hack DNS, steal a valid SSL certificate, then trick people into
going to their site.  But I think that's fairly true for any system and
the extra certificate doesn't add much if they've already gone that
far.  I guess it allows someone who has stolen a bunch of users'
passwords to stand up an SP and download their attributes from our
directory.  So we'd probably combine this with a pretty strict
attribute-filter.

I understand that signing is critically important in the SAML1
back-channel protocols, otherwise you could give a data dump of all user
attributes to some rando site.  But do we really need metadata for
SAML2.SSO, where the user is voluntarily giving their data to that SP? 
I figure the answer is "yes", and I am missing something important.

Related question: if the SP tries to sign its requests, is there a way
(in IdP3) to ignore the signature?  Right now, my testing triggers:

org.opensaml.messaging.handler.MessageHandlerException: Validation of
request simple signature failed for context issuer
        at
org.opensaml.saml.common.binding.security.impl.BaseSAMLSimpleSignatureSecurityHandler.doEvaluate(BaseSAMLSimpleSignatureSecurityHandler.java:214)

because it's trying to verify the signed request where no metadata is
present.  There are some old threads about how to turn off signature
validation in a relying party config for Shibboleth2, but I think the
config has changed too much for any of that to be relevant anymore. 
Note that I only want to try this in the UnverifiedRelyingParty
configuration.

-Eric Hattemer