Shibboleth Developers

["Howard Gilbert" <>]

> > Old Xerces supported two API techniques... 
> > Although this second approach was better suited to the SAML
> > and Shibboleth program model, the EntityResolver was more
> > commonly used in the code.
> 
> Actually, both were used. 

Hense "more commonly" rather than exclusively. If you look at the before and
after, there are many large blocks of entity resolver and error handler
routines that are dropped because this function can now be handled by the
shared common code.

> > Shibboleth only supports SAML 1.0 (and SAML 2.0 fortunately
> 
> Small nit, it's really 1.1 only at this point, 

Yes, typo. Meant 1.1. Sorry.


> Once it's checked in, I'm going to try and revisit the question of
> simultaneously supporting 1.0 and 1.1 in the SAML code. If it's doable, we
> can potentially support 1.0 more natively when we do the e-auth support.
> The
> filter Walter wrote is great for the time being, but it would be nice to
> be
> able to do something more elegant.

The OpenSAML XML class has public static references to a SAML 1.0 and SAML
1.1 Schema objects built during initialization from file lists. A namespace
based system (like BucketOSchemas) cannot process a single directory with
both SAML 1.0 and 1.1 XSD files (because they both try to define the same
namespace). However, you can create alternate Schema directories that are
namespace consistent, create multiple Buckets for each namespace, and then
construct customized subset Schema objects from them. Bottom line is, you
figure out what you want in the Schema, or how you want to specify the
Schema, and the code is basically there not only to create that combination
but also to maintain pools of parsers based on that grammar.