Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> > The other one I've seriously considered is to start issuing (signed) 
> > metadata files with specific rolling expiry dates.  There are real 
> > issues with that, though, one of them being that the signing process is 
> > currently manual and done far from the publishing site.  I'm no sure 
> > what the code will do, either.
>
> It will do what you want, so be careful what you wish for.

Good to know that it would Do The Right Thing.  Dire Warning acknowledged.

I do have concerns about whether it would be practical to foist this 
kind of approach on people without a lot of thought and consultation.

> > 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.

> Actually, I forgot about the IdP side. The SP side has issues with use of
> SSL in 1.2 with inline keys (as in they don't work, you have to fake it with
> self-signed keys entered as CAs).
>
> The IdP is much worse, it's like the Tomcat situation now.
>
> This is probably a 1.3 only thing for all intents and purposes, but since
> the 1.3 metadata is a different format...

I think that's an approximation of where I came in and is very easy to 
understand: any move away from PKI is a lot simpler if there is no 1.2 
around, so much so that I'd just call it a pre-requisite in practice. 
On the other hand, you can get the performance benefits of the inline 
key system on 1.3 systems in a mixed federation if you want by doing 
both CAs and key names, *plus* inline copies of the same keys.

Fair summary?

        -- Ian