Signature validation filter config

[Rod Widdowson]

With the simplest of credentials now being parsed I went back and added
this.

However there are two issues outstanding:

1) The default value for 'requireSignedMetadata' in V2 was FALSE.  As I
recall this was because of the order in which it was added (later than the
filter).  I feel reasonably strongly (but am prepared to be out-argued) that
we should take advantage of the version revision and flip this to be TRUE by
default. It stops an obvious attack when combined with the default
implementation.

2) There is the open issue around
https://wiki.shibboleth.net/confluence/display/DEV/IdP3Details

"The signature validation filter will have options that allow the
specification of public keys, certs, and CRLs instead of requiring a
separate trust engine to be defined (though that will still be supported)"

I missed the meeting in which this was discussed.  It is very easy to add
this, but I also feel that greater ease of use would be by *not* allowing
that, but a sub set - the certificate file

I'd guess that that 98% of people[1] will be configuring a
StaticExplicitKeySignature trust engine supplied with a X509Filesystem
certificate (which is what the template relying-party.xml ships with).
Hence it is needless work to make them supply all that stuff and we would
better to just add an attribute

certificateFile="MyFederation.PEM"

which would be mutually exclusive with 'trustEngineRef'.  

The remaining 2% can configure their metadata as they want.  Adding
'certificateFile' makes for more complication in the parser but not much.
It will give (IMO)  a much better end user experience - particularly if we
use property replacement on that file.

Thoughts?

Rod

[1] With the possible exception of SWITCH where ISTR that they use PKIX for
their metadata trust.