Skip to Content.
Sympa Menu

shibboleth-dev - RE: Dynamic metadata, API thoughts

Subject: Shibboleth Developers

List archive

RE: Dynamic metadata, API thoughts


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Dynamic metadata, API thoughts
  • Date: Wed, 28 Jun 2006 09:42:07 -0400
  • Organization: The Ohio State University

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

Authentication, however done, yes. That's how it probably has to work. Now
just imagine the set up for that at each provider. Scalability's great until
it becomes so complex you can't deploy it.

Note that with the new code, it's very simple to prune out just the entities
you need from a large file. Start up cost might be high, but runtime memory
usage could be very low. Or you could just load it all into a local database
cache, etc. Lots of ways to tackle scalability without a fully distributed
model.

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

Sure, but that doesn't require anything like the current design. Chad and I
have talked about it a bit today and I think we have some agreement on a way
to model it. The main difference in my thinking is that there should be a
small set (maybe one) of sophisticated resolvers that do the dynamic lookup,
and this should be invisible to the provider layer.

The provider shouldn't need to infer that it should create a new resolver
when it fails to obtain metadata, and the calling code outside the provider
shouldn't have to know anything about anything, because metadata usage
should be simple and transparent.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page