Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> > That has been our theoretical model, too.  I'm not happy that this 
> > leaves us dependent on people refreshing metadata to get revocations, 
> > because I know a lot of people just download it once and forget it.  I 
> > can't see that the situation gets any better from that standpoint if you 
> > move the keys into the metadata, though.
>
> I think it gets much better because it's really clear what a silly thing
> that is to do in an inline key world.

I'm not sure that people will connect the dots in this way and deduce 
the right answer.  I know myself how tempting it can be to stop thinking 
once something is "working".

> If people are not maintaining
> metadata, they will be vulnerable and someday will probably get screwed by
> it. Caveat emptor.

Um.  Well, you might think that I'd agree with that but I couldn't 
possibly comment ;-)

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.

One way we've considered adding to our policy is to do more monitoring, 
so that we can prompt people whose refresh has broken, as well as those 
who haven't set it up.

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.

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

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.

> Their systems will also fail any time a key changes. This
> is currently viewed as "bad" by some, but I think I disagree with that.

This I can agree with, though, although keys probably change 
sufficiently infrequently to really prompt people to automate the process.

> > Correct me if I'm wrong, but the other pre-requisite would be that all 
> > entities were running at least Shibboleth 1.3, because 1.2 doesn't know 
> > about explicit keys in the old-style metadata.  I realise that may be 
> > implicit from where you're standing.
>
> Well, 1.2 sort of does because you can put inline keys in the trust file.
> There are some caveats wrt SSL usage, but it can be made to work. But no, I
> haven't really studied that aspect, I just know 1.3 would be oblivious to
> it.

Ah, interesting, I think I knew this at some level but we've never made 
use of it.  Of course, my handy-dandy XSL stylesheet doesn't perform 
this conversion, but that doesn't mean that it couldn't.

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?  I 
think that means that going over to inline keys would be a fair bit 
easier if there were no 1.2 IdPs, but 1.2 SPs would be pretty 
straightforward given some more XSL...

        -- Ian