Shibboleth Developers

["Scott Cantor" <>]

> Seriously, you're obviously right at some level, but I'd like to see if 
> there are ways to prompt people to keep up to date that don't involve 
> them being screwed over by a hacker as part of the learning experience.

I think the world of computer platform security suggests this is roughly
like bringing world peace.

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

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

> The upside is that this might be a lot easier to 
> configure, and harder to get wrong.  The downside is that if the 
> metadata publishing site isn't up, bad things will (gradually) happen as 
> local caches expire.  With separate metadata refresh applications, if 
> they can't fetch it, they just get to try again next day.

It's much worse than that...metadata isn't cached to disk, just memory.
Restart, site down, you break.

> Just thinking out loud here, really.  I think my bottom line is that 
> some way of making this automatic for people that doesn't have to be 
> separately configured is a better long-term solution than requiring 
> people to deduce how vital refresh is from first principles.

It would be, but short of reproducing a system with the reliability of DNS,
I question the feasibility...

> I guess the SSL caveat is going to be related to the fact that in 1.2, 
> the IdP's certificate checking is being done by Apache, which really 
> wants to talk about self-signed root certificates and intermediates?

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

-- Scott