Shibboleth Developers

[Chad La Joie <>]

Hey Jim,
  Scott and I found the problem.  The reason I wasn't seeing what you 
mentioned is just because I didn't recognize the error I was getting as 
what you were describing.  Turns out that Xerces changed a default 
setting in the new version that Shib 1.3c now uses.  This new library 
was included because the Sun libraries had horrible memory leaks.

Anyway, the setting allowed DOM node expansions to be deferred.  When 
the SAML Assertion was retrieved from the cache and re-parsed into a DOM 
 tree most of the nodes where touched, because the OpenSAML code 
touches them, however at least one wasn't.  The exception indicates it 
was an attribute node, but doesn't say which.  Anyway, when the 
reclaimed Assertion was put into a SAML Response object and that object 
was then serialized to a string for transport over the network a call to 
adoptNode was made (so that the Assertion would live in the same 
Document as the Response).  This call bombs when it encounters a 
deferred node (which is probably a bug in Xerces).

So, anyways, that's the story.  Scott just patched OpenSAML, I'll 
probably submit a bug report to Xerces, and if we feel this is a big 
enough issue (and I'm not sure it is at the moment) we may elect to 
release another round of version for OpenSAML and Shib.

Jim Fox wrote:
> >  I finally got some time to work on this again, but I was not able to 
> > reproduce you're problem.  What's your environment like (JDK, Tomcat, 
> > versions, etc)?
>
>
> Which problem?  all of them?
>
>
> One system:  Linux 2.4.21-4.ELsmp
>              Apache 2.0.52
>              Tomcat/5.5.4
>              Java 1.5.0_01
>
> Other system: Linux 2.4.21-27.0.2.ELsmp
>               Apache 1.3.33
>               Tomcat/5.5.9
>               Java 1.6.0-ea-b55
>
>
> Without the clone of the recovered, serialized  assertion we get a
>
>   java.lang.ClassCastException: org.apache.xerces.dom.DocumentImpl
>
> when attempting to deserialize the assertion.  This causes
> an error 500 response the the attribute query.
>
>
>
> Without the cache loader we get 'artifact not found' errors.
>
> Jim
>
>
> > Jim Fox wrote:
> >
> > > We've done some testing of clustered E-Auth CS (IdP) servers
> > > using Chad's JBoss replication method.
> > >
> > >  http://www.middleware.georgetown.edu/dokuwiki/doku.php/projects:hashib:home 
> > >
> > > Initial results look promising.  We had to make a couple of changes 
> > > to get it to work.
> > >
> > > 1) In the ReplicatedArtifactMapper class we had to use a clone
> > >    of the recovered assertion [ cacheObject.getAssertion() ]
> > >    when creating the artifactMapping.  (Something to do with
> > >    the DOM classes needing a 'deep' copy of the tree.)
> > >
> > > 2) We didn't get any replication until adding a cache loader.
> > >    Specifically added this to the config:
> > >
> > >      <attribute name="ReplQueueMaxElements">0</attribute>
> > >      <attribute name="FetchStateOnStartup">true</attribute>
> > >      <attribute 
> > > name="CacheLoaderClass">org.jboss.cache.loader.FileCacheLoader</attribute> 
> > >
> > >      <attribute name="CacheLoaderConfig">
> > >         location=/tmp/
> > >      </attribute>
> > >      <attribute name="CacheLoaderShared">false</attribute>
> > >      <attribute name="CacheLoaderPreload">/</attribute>
> > >
> > >
> > > We used this just for artifact retrieval, didn't try the the
> > > ReplicatedHandleMapper.  Also didn't try the encrypt mode.
> > > Will probably use an openvpn encrypted channel instead.
> > >
> > >
> > > Jim
> >
> > --
> > Chad La Joie             315Q St. Mary's Hall
> > Project Sentinel         202.687.0124

--
Chad La Joie             315Q St. Mary's Hall
OIS-Middleware           202.687.0124