Shibboleth Developers

["Howard Gilbert" <>]

> Howard, I had to take more guesses about the SP, mainly because I was
> ripping out the xmlbeans copies, and I didn't understand all the plugin
> stuff. Java shouldn't need indirect reflection into the plugin layer like
> C++ does, so I don't know what that's all for.

XMLBeans is an XSD compiler and a set of backing classes. It converts the
XSD files into a jar of classes that reflect the Schema in types that are
natural to Java. If you have another class that accurately reflects the
interface, then it should be possible to simply replace it as you appear to
have done.

Previously the format of Metadata was different for the SP and the IdP, so I
used the simplest technology I had to provide the additional parse. Later I
added an alternate plugin for SAML 2 Metadata format just to test the
design. However, Metadata should now be a unified concept for both SP and
IdP, so it makes sense they should now share a class that handles it for
both of them.

> For now, I tried to wrap the new plugin inside of the serviceprovider
> metadata plugin class and hope it will work for the time being, and you'll
> have to review it.

I will test it and report any fixes needed. For example, a quick look notes
that you try to cast the Node passed to Initialize to a Element, but the
configuration file passes an Element for Inline XML and a Document for XML
read in when a URL is provided to an external file. So I have to test and
drill down to the first child Element of the Document. That may be the only
problem, but if not it's the type of small fix needed.

> The trust plugins shouldn't need to manage any of that data, or have
> access
> to the XML data feed, they should be able to cast down and locate extended
> material when they need it. That way there's only one copy of the metadata
> pathname in the config file instead of duplicating it for each type of
> plugin once there's only one file.

Wouldn't imagine anything else. If the Metadata interface exposes methods to
access the embedded Trust information, then the Trust plugin should use it.
As I look at the current Trust code, it can be passed a RoleDescriptor for
the partner Role. If not, there is code to extract a partner Entity from the
SAMLObject being validated and look up the Entity through a Metadata
interface argument. However, if the Keys are based in the Role, I don't
think the Metadata lookup fallback is going to work any more. I suggest
dropping that argument and require that the RoleDescriptor be non-null.

This works if you can chain up to the Key Extension data "internally" from
the Role to the Entity to the Entities without having to come in from the
outside with a new "lookup" call.