SP metadata expired?

[Peter Schober]

* Morris, Andi <amorris at cardiffmet.ac.uk> [2013-03-15 12:38]:
> I've also grepped for valid_until, which only appears in the UK
> federation metadata, as expected.

It's written validUntil, but OK (if you found any, it was written that
way).

> I've also added the requireValidMetadata="false" to the relying
> party for that SP, but still I get:

If you're adventerous you could set this to true and see whether that
makes the service unavailable (preferrably on your test IDP).

> 11:29:53.314 - DEBUG
> [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:132]
> - No custom relying party configuration found for
> https://login.ezproxy.uwic.ac.uk, looking up configuration based on
> metadata groups.

That does not match what you're saying below, that you have a custom
relying party for every of your SPs.

> 11:29:53.314 - DEBUG
> [edu.internet2.middleware.shibboleth.common.relyingparty.provider.SAMLMDRelyingPartyConfigurationManager:155]
> - No custom or group-based relying party configuration found for
> https://login.ezproxy.uwic.ac.uk. Using default relying party
> configuration.
> 
> We currently have separate metadata files for all our SPs, is this
> the right way to do it, or should I chain them into one file?

There is no "right way" but no, it's not expected to be used like
that. If you put all your local SPs into a single metadata provider
and make that reloadable (it is by default, contrary to
relying-party.xml) you save yourself bouncing the IdP (thereby
destroying everyone's SSO session; unless you run a cluster) or making
relying-party.xml auto-reloadable (which I have use for).

> I'm really confused why the debug references custom and default
> relying-party configs.

If you look at relying-party.xml it has three relying party types:
AnonymousRelyingParty (mostly SPs you know nothing about, i.e., no
metadata), DefaultRelyingParty (all your SPs for which don't have a
more specific relying party config) and RelyingParty (specific
overrides for outliers which you cannot or don't want to deal with via
DefaultRelyingParty settings, e.g. broken SPs which require special
handling).
So that's all good. What is off is that it doesn't match what you said
about having custom relying parties for every SP.

You could start by posting the relevant relying party entry from your
relying-party.xml
-peter