OpenSAML user discussion

[Terry Cumming <>]

Scott, I changed the sign/verify boolean to "false" from "true" so that the
XPath syntax was used. This worked on one instance. The SAMLRequest can now
be signed and verified without error which is good.

My next problem is signing the resultant SAMLResponse to be sent back to
the requestor. This fails with the stack trace shown below. If I make
standalone test code and sign the SAMLResponse there, it works. In the real
code running within the Tomcat servlet container, it fails. So this makes
me think I have an environmental problem. 

I have xalan-2.4.1.jar in the javahome/jre/lib/endorsed directory of my JDK
1.4.1_02 installation. I also added it to the common/endorsed directory of
my Tomcat instances. Any ideas?

Thank you.

Terry Cumming

java.lang.IllegalAccessError: Since it seems that nobody reads our
installation notes, we must do it in the exception messages. Hope you read
them. You did NOT use the endorsed mechanism from JDK 1.4 properly; look at
<http://xml.apache.org/security/install.html> how to solve this problem.
Original message was "tried to access field
org.apache.xpath.XPathContext.m_dtmManager from class
org.apache.xml.security.transforms.implementations.FuncHereContext"
        at
org.apache.xml.security.transforms.implementations.FuncHereContext.<init>(Fu
ncHereContext.java:177)
        at
org.apache.xml.security.utils.CachedXPathFuncHereAPI.eval(CachedXPathFuncHer
eAPI.java:294)
        at
org.apache.xml.security.utils.CachedXPathFuncHereAPI.selectNodeList(CachedXP
athFuncHereAPI.java:239)
        at
org.apache.xml.security.transforms.implementations.TransformXPath2Filter.eng
inePerformTransform(TransformXPath2Filter.java:205)
        at
org.apache.xml.security.transforms.Transform.performTransform(Transform.java
:333)
        at
org.apache.xml.security.transforms.Transforms.performTransforms(Transforms.j
ava:260)
        at
org.apache.xml.security.signature.Reference.getContentsAfterTransformation(R
eference.java:510)
        at
org.apache.xml.security.signature.Reference.dereferenceURIandPerformTransfor
ms(Reference.java:701)
        at
org.apache.xml.security.signature.Reference.getReferencedBytes(Reference.jav
a:765)

        at
org.apache.xml.security.signature.Reference.calculateDigest(Reference.java:7
90)
        at
org.apache.xml.security.signature.Reference.generateDigestValue(Reference.ja
va:441)
        at
org.apache.xml.security.signature.Manifest.generateDigestValues(Manifest.jav
a:214)
        at 
org.apache.xml.security.signature.XMLSignature.sign(XMLSignature.java:529)
        at org.opensaml.SAMLSignedObject.sign(SAMLSignedObject.java:258)

At 11:13 AM 31/03/2003 -0500, Scott Cantor wrote:
>> However, in my real code, I still get the same problem with 
>> the bad signature value (trying to verify signature of 
>> SAMLRequest received via SAMLSOAPBinding). I did find a 
>> workaround however. If I simply streamed the SAMLRequest 
>> object out then immediately created a new SAMLRequest with 
>> the constructor taking that stream as input, then the verify 
>> is successful.
>
>I finally remembered why last night. If you want to verify a signed
fragment inside of a SOAP message like that, you can't use the
>"simple" transform profile that my library uses when you pass true into
the sign method. You need to tell it to use the full XPath
>syntax to isolate the Request element from the SOAP message. If you do
that, the signature should verify. Try passing false into the
>sign call.
>
>Your trick works, because once you stream out the Request, it's then
stand-alone, and will verify just like a Response does in the
>POST profile.
>
>The only place in SAML where signing is currently dictated is the POST
profile, not the SOAP binding. And there, just using true
>will work fine.
>
>All of this is in flux as I debug the code, figure out what the right
signing strategies are, and as SAML evolves toward 1.1 with an
>apparent intent to add ID attributes that will facilitate signing. This is
the aspect of the API that is likely to get changed.
>
>> The next problem occurs when I attempt to sign the 
>> SAMLResponse (containing a single unsigned assertion to go 
>> back to the requestor). The
>> SAMLSOAPBindind.respond() operation fails with: 
>
>I'll try and run your code this week and see what the bug is. Make sure
that you are consistent in the Document you use to create
>the various objects when you call toDOM() (if you actually call it
youself). The bug is due to a mismatch in documents.
>
>-- Scott
>
> 

---------------------------------------------------mace-opensaml-users-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

---------------------------------------------------mace-opensaml-users--