OpenSAML user discussion

[Daniel Förberg <>]

I found out why getDOM() was null as written below, but the verification issue i do not
understand yet. Hope to get a clue soon, so i can solve this problem. I have a number
of task on my list to workaround or find another solution, maybe using a another frame-
work than OpenSAML to verify the signature, for example SUN correspondant. But first
i want to know how to solve this problem. It's definitely api related cause using OpenSAML
on both sides. Thanks in advance.

Regards,

Daniel

2011/1/14 Daniel Förberg <>

Now i have debugged/tested the code as much i can understand right know. Came
to a conclusion, that actual pre-digest differs, cause it seems to use another Assertion,
according to the pre-digest output in the log than it should use. Which is very strange
because i pass the right Assertion to validation method. Then i started to think if there
is something wrong with the unmarshalling. It works fine to validate the Assertions
in isolation, but not while extracting the Assertions from a SOAP Message, using
OpenSAML, XMLSec on both sides. It should'nt be a problem or ?

This block falis while verifying signature:
Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(Assertion.DEFAULT_ELEMENT_NAME);
Assertion authenticationAssertion = (Assertion) unmarshaller.unmarshall(assertionElement);
Assertion authorizationAssertion = (Assertion) unmarshaller.unmarshall(assertionElement);
Assertion auditAssertion = (Assertion) unmarshaller.unmarshall(assertionElement);

the getDOM() returns null

This block successfully verifies the signature
Unmarshaller unmarshaller = unmarshallerFactory.getUnmarshaller(Assertion.DEFAULT_ELEMENT_NAME);
assertion = (Assertion)unmarshaller.unmarshall(assertion.getDOM());

Can someone clearify this for me ?

Thanks in advance.

Cheers

Best regards,

Daniel

2011/1/12 Cantor, Scott E. <>

> Well do know how to enable debug level in Java no problem.
> But i just wanted to make shure that i look for the right output.
> It was written at the INFO level while verifying signature, but
> not while signing, though there is a precalculated digest value
> in the assertion. This value is recalculated and is not correct.

The digest isn't the issue, it's what is hashed to create the digest that has to be compared on both ends.

> The reason to this i don't know yet, but if the content has been
> changed of any reason, which it should not have been. It does
> work before i put it in the SOAP Header both signing and
> verification using a TrustEngine loading from the truststore.

There are many complex namespace issues that can create problems in a SOAP context. Changing the document is merely one source of problems.

-- Scott