Shibboleth Developers

["Scott Cantor" <>]

> I understand, thank you for your time in explaining this. If I wanted to
> learn more about the metadata API where would you suggest starting? I've
> read the Wiki pages that relate to metadata and trust management.

There isn't a whole lot to the API; it's very SAML centric for no particular
reason other than this being a SAML project.

The APIs in 1.3 are irrelevant and will be dead soon. They're similar in
this particular area, but more limited. None of the APIs in either branch
have documentation yet. We can't even find the time to finish user
documentation let alone developer material. There are fairly accurate
javadocs and doxygen API docs for both code bases, however.

In 2.0, the metadata APIs are in opensaml, apart from some extension objects
specific to Shibboleth (like the PKIX extension, for example). In 1.3 that
was all inside the Shibboleth code.

In general, a metadata provider is just responsible for answering lookups
like "get me the entity named foo" or "get me the SAML 2.0 IdP role for
entity bar". The actual data presented is a SAML metadata interface, all the
information is abstracted behind that.

Metadata providers can be "observable", so that external layers can detect
when the contents change, and they can use filters to apply rules about what
data to store and what to throw away.

So far, we've easily written batch and dynamic caching plugins in both
languages, and I've written filters that can blacklist, whitelist, and
verify signatures using a number of different trust models. I drew the line
at any form of transport authentication because it's much more difficult.

It would be relatively trivial to write something using a database, the
eduGAIN metadata service, etc.
 
-- Scott