Shibboleth Developers

[Jim Fox <>]

> > > Actually, going to dynamic metadata might help address this as you could 
> > > use the cacheDuration to prevent things getting stale.  This needn't be 
> > > per-entity metadata, just integrating the federation metadata fetch (and 
> > > signature check) into the IdP and SP instead of using an external 
> > > application.
> >
> > It's easy to support URL fetch even now, but people objected to the remote
> > point of failure, so tabled the idea.
>
> I don't think it makes sense unless there is some mechanism for local 
> (persistent) caching (even just in a file) so that momentary outages don't 
> take your site down.  It doesn't seem to me that this would be *very* hard to 
> do, though.  I'm really talking about something not much more sophisticated 
> than having the code for siterefresh run every so often under the control of 
> the SP (or IdP).  Integrating it would potentially simplify things a lot for 
> sites deploying the system, though.

Setting aside the totally absurd notion that someone can setup a
shibboleth IdP or SP, yet be incapable of running a simple cron
task, the entire methodology of client-pull of metadata from a
federation repository is backwards.  It is the federation that
knows when something has changed - not the clients.

Consider the simple case of a compromised key on an IdP.  The IdP
administrator immediately notifies the federation, which updates
its metadata, deleting the old certificate and inserting a new one.
The shibboleth 'standard' is metadata refresh every 24 hours.
Now can anyone in his right mind state that, by design, an SP should
continue to accept the old and now bogus certificate for another
24 hours?  12 hours? 1 hour?

Either you poll the federation for new metadata every minute or so,
or you manually notify every possible peer of a compromised key,
or you allow the federation to push new metadata to its members.

This is the same reason CRLs are all show and no substance -
no sense of urgency.

Jim