I'm not sure about Axis2 but with Axis1, messages go through some
processing (they effectively get deserialized and re-serialized) before
the XML signature is verified. This is a problem because there's no
guarantee that XML canonicalization will be preserved during message
processing.
The enableNamespacePrefixOptimization switch was added to fix a
particularly common problem where optimizing away unnecessary XML
prefixes would break the canonicalization rules. As your finding out
now, that switch doesn't really address the root of the problem because
messages can still be modified by Axis before signature verification.
The last time I looked at the Axis1 code, I didn't see an easy way to
avoid this potential modification of the message. Signature processing
happens via a WSS4J message handler after it's gone through Axis. Either
the signature verification needs to happen earlier (before Axis mucks
with things) or Axis needs to be careful to preserve XML canonical form
during message processing. Neither change seemed straightforward to me,
which is why things are the way they are now. Maybe someone more
familiar with the Axis codebase could give some guidance here?
David
Rohit Chauhan wrote:
Did any one find the resolution to this issue?
I am facing same problem.
I can get the saml signature and message signature
verified if I create the
assertion without namespaces using
org.opensaml.SAMLAssertion
with "enableNamespacePrefixOptimization" set to
"false"
But now I am getting the assertion from an outside STS
server with "saml" prefix.This results in SAML
signature verification failure.
-Rohit
*****************************************************
Hi all,
i first encountered the XML signature verification
problem generated by
the serialization mechanism of Axis 1.x when
starting to use wss4j SAML
support based on OpenSAML 1.0.1.
To create an SAML assertion uses
org.opensaml.SAMLAssertion that
creates assertions this way:
<Assertion
AssertionID="_c7ecbec589fb83a6aff2176535125169"
IssueInstant="2006-07-24T16:26:22.000Z"
Issuer="myissuer"
MajorVersion="1" MinorVersion="1"
xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
....
</Assertion>
When this assertion is signed it shouldn't be modified
before sign
verification, but this not the way Axis serialization
works when you set
the "enableNamespacePrefixOptimization" parameter to
"false".
In such a case, regardless of the format of the SOAP
message received on
the net (with or withoute the prefix) the assertion
will be modified in:
<saml:Assertion
AssertionID="_c7ecbec589fb83a6aff2176535125169"
IssueInstant="2006-07-24T16:26:22.000Z"
Issuer="myissuer"
MajorVersion="1" MinorVersion="1"
xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
....
</Assertion>
breaking signature verification.
Naturally setting the
"enableNamespacePrefixOptimization" parameter to
true solves this problem, but then this workaround can
create a
situation that seems an unsolvable problem to me.
As you know the "enableNamespacePrefixOptimization"
parameter was
introduced to solve a specular problem to that of my
SAML assertion,
when we have a SOAP body like this:
<soapenv:Body wsu:id="id-23412344"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004";>
<somepfx:SomeTag id="e0sdoaeckrpd"
xmlns="ns:uri:one"
xmlns:somepfx="ns:uri:one">hello</somepfx:SomeTag>
</soapenv:Body>
this can work when received in Axis only if you set
"enableNamespacePrefixOptimization" parameter to
"false" otherwise the
signature validation will fail as the message would be
changed in:
<soapenv:Body wsu:id="id-23412344"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-2004";>
<SomeTag id="e0sdoaeckrpd" xmlns="ns:uri:one"
xmlns:somepfx="ns:uri:one">hello</SomeTag>
</soapenv:Body>
see: https://issues.apache.org/jira/browse/AXIS-1624
for a discussion of
the problem an the solution proposed.
And now the unsolvable problem:
if i have a SOAP message with a SAML assertion and a
SOAP body like in
my example and i sign both, a receiving Axis service
will not be able to
validate both signatures:
-if i set "enableNamespacePrefixOptimization"
parameter to "false" the
SAML assertion signature validation will fail
-if i set "enableNamespacePrefixOptimization"
parameter to "true" the
SOAP body signature validation will fail.
Changing the SOAP clients can't be a solution, as they
are not always
under our control :)
Any idea on how to deal with this "deadlock"?
I tested only Axis 1.3 and 1.4. is there anyone using
Axis2/Axiom that
can report if the same problem still exist in this
release?
Regards,
Luciano
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
