Shibboleth Developers

[Ian Young <>]

Scott Cantor wrote:

> [sending this to shib-dev, as I'd like to try and get more of this type of
> coding discussion happening in the open]

Odd to think I'm the first person to comment on this, but maybe the 
context is sufficiently arcane for most people to have no comment.  Or 
maybe I'm the only person who cares about dynamic metadata ;-)

> I don't want to make this a priority, because I think the viability is
> unproven,

Per my comment in another thread, if we're talking about dynamically 
fetching individual entity metadata documents from the URL that is the 
entity's ID, we're probably mainly thinking about scalability.  And, 
most people aren't currently seeing scary scalability issues in their 
future just yet, so maybe they don't see this as worth worrying about 
just now.  I do see scary scalability issues in my future, though.

As to viability at a technical level, my biggest question is that I 
can't see how to combine the fetch-from-the-ID approach with an entity 
retaining its entity ID in multiple federations.  One issue is the 
signing question: the signature profile used in SAML metadata doesn't 
allow for multiple signatures on the same metadata, so how does the 
location being queried for metadata know which signed metadata to 
return?  Query parameters?  Client TLS authentication?  I don't think we 
know.  Unless we declare this a non-problem (and return to entities 
having different IDs in different federations) we'd need to profile 
something and obviously the contextual information you need to pass 
across for this operation would need to be available through the 
resolver API.

> With dynamic lookup, the URL is the entity. So you'd really have just one
> Resolver instance, I think, whose job was to do the lookup based on the ID.
> So does it even make sense to think about "pre-loading" the cache? I don't
> think so.

If you're doing dynamic, you might be concerned that the first time you 
talk to an entity there will be a delay while you go off and fetch the 
metadata for it.  So, there might be a case for the API allowing you to 
pass in a set of IDs that should always be kept fresh, and reloaded 
whenever they became stale or expired.  You'd pre-load that set, of 
course, at startup.

> It seems like, as in the old code, what you have with the Provider is a
> wrapper around a bunch of prospective resolvers, each of which would offer
> the basic lookup() method. If I hand some dynamic ID to the Provider, I
> would expect it to just invoke the Resolvers in turn until it found the
> answer, and at some point that would hit this single "dynamic" Resolver,
> hand it the ID, and if by some magic that worked, you'd get back (and could
> cache) the result.

As above, there might be a case for a layer of pre-fetching in this 
particular resolver.

        -- Ian