Skip to Content.
Sympa Menu

shibboleth-dev - RE: XML API changes in OpenSAML and Shibboleth about to be checked in

Subject: Shibboleth Developers

List archive

RE: XML API changes in OpenSAML and Shibboleth about to be checked in


Chronological Thread 
  • From: "Scott Cantor" <>
  • To: "'Howard Gilbert'" <>, <>
  • Subject: RE: XML API changes in OpenSAML and Shibboleth about to be checked in
  • Date: Tue, 25 Jan 2005 15:35:05 -0500
  • Organization: The Ohio State University

Thanks for this, just a couple small notes...

> Old Xerces supported two API techniques. One, suited for the
> first case where the XSD schema file name was part of the
> XML, used a SAX interface called the EntityResolver. This
> callback routine received the string from the XML, and
> located the XSD schema file to which the string referred. An
> alternate approach was available in which an array of open
> XSD Schema files was passed to the DOMParser in advance.
> 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. The purpose of using the EntityResolver was to
avoid having to rely on the file system to store and locate the schema
files, since file access is discouraged by the servlet spec, and at the
time, caching the loading of the files seemed important (the alpha code
predated the ability to cache the grammars in the parser). JAXP 1.3 clearly
supersedes all of that extra hassle.

> Shibboleth only supports SAML 1.0 (and SAML 2.0 fortunately

Small nit, it's really 1.1 only at this point, not 1.0. However...

> Of course, this work would only be useful if you intended for
> Shibboleth to have more than one Schema object with specific
> subsets of namespaces. After kicking this question back and
> forth, I propose that there be only one composite Schema
> object. Thus BucketOSchemas is not currently used for any
> really useful purpose. However, having written it, there was
> no reason to discard it. So the code will be checked in and
> available if the function is needed later.

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.

So please do include this.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page