OpenSAML and Apache Santuario (xmlsec) 1.5.1

[Stephanie Stroka]

Hey Brent,

thanks for testing and investing your time into that!
I may have figured out what causes the trouble.
Though I'm still not sure about how to resolve it.

First of all: unmarshalling non encrypted messages seems to work fine, 
except when the unmarshalled msg is marshalled again for 
logging/debugging purposes: This causes the Id to be lost.

The second problem may be caused by using 
org.opensaml.saml2.encryption.Decrypter	to decrypt an 
org.opensaml.xml.XMLObject:

There's the stack trace to where I figured out the problem:

Thread [main] (Suspended)	
	AssertionUnmarshaller.processAttribute(XMLObject, Attr) line: 81	
	AssertionUnmarshaller(AbstractXMLObjectUnmarshaller).unmarshallAttribute(XMLObject, Attr) line: 239	
	AssertionUnmarshaller(AbstractXMLObjectUnmarshaller).unmarshall(Element) line: 108	
	Decrypter(Decrypter).decryptDataToList(EncryptedData, boolean) line: 467	
	Decrypter(Decrypter).decryptData(EncryptedData, boolean) line: 400	
	Decrypter.decryptData(EncryptedElementType) line: 141	
	Decrypter.decrypt(EncryptedAssertion) line: 69	
	Decrypter.decrypt(XMLObject) line: 152	
	Decrypter.decryptWhereNeccessary(XMLObject, EncryptionPass) line: 193	
	Decrypter.decryptWhereNeccessary(XMLObject, EncryptionPass) line: 209	
	Toolbox.verifySignature(SignableSAMLObject, String, AuthRequest, 
AuthResponse) line: 1477	
	ServiceProviderState.consume(Response, AuthRequest, AuthResponse) 
line: 223	
	ServiceProviderState.authenticate(AuthRequest, AuthResponse) line: 920	
	ServiceProviderState(AuthState).process(AuthRequest, AuthResponse) 
line: 91	
	AuthStateHarness.process(TestContext) line: 154	
	AuthStateHarness.authenticate(TestContext) line: 169	
	tSAMLUnitTests.encryptAssertion_redirect_noKeyInfo() line: 148	
	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not 
available [native method]	
	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
	Method.invoke(Object, Object...) line: 597	
	FrameworkMethod$1.runReflectiveCall() line: 44	
	FrameworkMethod$1(ReflectiveCallable).run() line: 15	
	FrameworkMethod.invokeExplosively(Object, Object...) line: 41	
	InvokeMethod.evaluate() line: 20	
	BlockJUnit4ClassRunner(ParentRunner<T>).runLeaf(Statement, Description, 
RunNotifier) line: 263	
	BlockJUnit4ClassRunner.runChild(FrameworkMethod, RunNotifier) line: 69	
	BlockJUnit4ClassRunner.runChild(Object, RunNotifier) line: 48	
	ParentRunner$3.run() line: 231	
	ParentRunner$1.schedule(Runnable) line: 60	
	BlockJUnit4ClassRunner(ParentRunner<T>).runChildren(RunNotifier) line: 229	
	ParentRunner<T>.access$000(ParentRunner, RunNotifier) line: 50	
	ParentRunner$2.evaluate() line: 222	
	RunBefores.evaluate() line: 28	
	RunAfters.evaluate() line: 31	
	BlockJUnit4ClassRunner(ParentRunner<T>).run(RunNotifier) line: 292	
	JUnit4TestAdapter.run(TestResult) line: 39	
	JUnitTestRunner.run() line: 421	
	JUnitTestRunner.launch(JUnitTest, boolean, boolean, boolean, boolean, 
boolean, boolean, Properties) line: 912	
	JUnitTestRunner.main(String[]) line: 766	
	

processAttribute(..) calls 
attribute.getOwnerElement().setIdAttributeNode(attribute, true)
which should register the ID attribute as an id.

Here's the content of attribute:

"attribute"		(id=96)
	flags		680
	localName	"ID"
	name		"ID"
	namespaceURI	null
	ownerNode 	ElementNSImpl (id=100)
	type		null
	value			"Assertion_d0bd8dd5b6d9b37731d6df773b369fde83408f45"

However, I wanted to verify that the ID is indeed registered, so I called
attribute.getOwnerElement().getOwnerDocument().getElementById("Assertion_d0bd8dd5b6d9b37731d6df773b369fde83408f45")
in the debugger and null is returned.

Do you have any ideas what might have gone wrong?

We are using xerces 2.9.1 and xalan 2.7.0.
To be honest, I've no idea how it has been endorsed into the JVM nor do 
I know anything about you install instructions ;-).
This project that I'm working on is about 10 years old and I just 
started 1 month ago.

I am using Java hotspot 1.6.0 under Linux x86 32bit, but the testing 
environment also (additionally) runs on 64bit Linux and under Solaris.

Steffi



On 04/12/12 23:18, Brent Putman wrote:
>
>
> On 4/12/12 1:12 PM, Brent Putman wrote:
>> I have not tried running OpenSAML v2 with the newer Santuario yet.  I'll
>> do some quick tests later today or tomorrow to see if I experience the
>> same issue.
>
> I did some testing. I was not able to reproduce this by just switching
> OpenSAML 2 to use 1.5.1.  All our signature signing and validation tests
> work fine for me.
>
> Your and Scott's comments about the SAML signature profile validator
> made me realize that the ID-ness of the attributes and their resolution
> can't be fundamentally broken in OpenSAML, and the Santuario IdResolver
> must be finding the ID's by DOM search and not by the fallback behavior
> that was removed in 1.5.0.  If that were the case, we'd be seeing
> routine failures of things in the profile validator, which uses the DOM
> search exclusively, before it even attempted to validate the signature.
>
> I also confirmed this by turning on DEBUG logging level for category:
> org.apache.xml.security.utils.IdResolver.  With 1.4.x, I  see output
> similar to the following:
>
> DEBUG IdResolver - getElementByIdType() Search for ID
> _b32801700a13922734aeb359f296ddac
> DEBUG IdResolver - getElementByIdUsingDOM() Search for ID
> _b32801700a13922734aeb359f296ddac
> DEBUG IdResolver - I could find an Element using the simple
> getElementByIdUsingDOM method: saml2:Assertion
>
> The line about getElementByIdType() is a little misleading - looking at
> code, what that really does is attempt to resolve from the IdResolver
> cache, nothing more.  The last line indicates a successful resolution
> via the DOM method (despite the slightly awkward English phrasing there).
>
> In order to troubleshoot what's going on in your environment, you might
> try reverting back to 1.4.x, and turning on the debug logging above.  I
> suspect you'll see the first 2 lines, but not the "I could find..."
> line, which would mean the DOM search is failing.  Unfortunately, it
> doesn't explicitly log anything when it then does the manual search
> against well-known namespaces, but the absence of the "I could find..."
> line in conjunction with a successful resolution and signature
> validation would confirm that is what it's doing.
>
> Also, if you are running the SAMLSignatureProfileValidator, it shouldn't
> matter what version of Santuario you are using.  The DOM search there
> should fail if the ID-ness is lost, so that could be an indication of
> the problem.
>
> Since it's been working for a large number of people, I'd suspect
> either: 1) something you are doing after parsing but before validation
> is changing the DOM, as you earlier suggested or 2) an environment issue
> with your XML parsing environment.  Can you check and confirm what
> version of Xerces and Xalan you are using, and that you have properly
> endorsed them in your JVM per our install instructions?  If there is an
> issue with some combination of Xerces and Xalan, or a bug in some
> version of those libraries, we'd love to uncover that.
>
> Also, on what JRE vendor, version and OS platform are you seeing this error?
>
>
> --
> To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net