Relying party parsing. Metadata providers

[Rod Widdowson]

> >I have not reviewed the filters yet, I do not foresee difficulties in
> >there
> >(but who knows)
> 
> The filters are where the security schema comes in, of course.

Yea I realized that about an hour after I sent it.  I have a couple of ideas
on how to deal with that - strictly speaking they were yours.  I'm not too
terrified by them - yet.  Actually the SchemaValidation filter is probably
the scariest one right now, but that may be because I've not looked at
signature too closely.  I'll certainly be mailing around once I do have my
mind around filters.

> Which are deprecated? We may just want to pull them, since this is a major
> upgrade.

On ResourceBackedMetadataProvider there is "maxCacheDuration" with the
comment "This property is deprecated, use maxRefreshDelay instead"

On HttpMetadataProvider, FilebackedHttpMetadataProvider and
FileSytemMetadataProvider there is "maintainExpiredMetadata" with the
comment "This is deprecated, use requireValidMetadata instead".

It looks as though these were deprecated as recently as May 2010  (SC-102)
and release in September of that year (Shibboleth-common:1.2/IDP
release2.2.0)

> You mean literally just turning the HTTP case into the other HTTP resolver
> on the fly?

Absolutely, so: 

FilesystemResource=> FilesystemMetadataResolver
HttpResource=>HTTPMetadataResolver
FileBackedHttpResource=>FileBackedHTTPResolver

Leaving ClasspathResource and SVNResource to go via the
ResourceBackedMetadataResolver.  At that stage there will be a temptation to
remove the HTTPResource from Spring-utils, but I am pretty sure that MDA
users will need it.  Indeed I suspect that the bridge classes needed to
handle the Spring/HttpClient impedance mismatch may end up there for the
benefit of MDA users.

/R