Nandana,
I picked up nightly build 216 last Friday and tried it out with
policy/sample.02. The server fails to validate the signature because it
is expecting an X509V3 certificate and is getting an X509V1 one. I
tried changing both policy.xml and services.xml to specify both the
initiator and recipient tokens as X509V1Token11 but it didn't help. Both
the client and service certificates are V1.
It verifies the input signature:
2008-10-03 15:52:31,502 [HttpConnection-8081-1] INFO
org.apache.xml.security.signature.Reference - Verification successful
for URI "#Id-5212446"2008-10-03 15:52:31,506 [HttpConnection-8081-1]
INFO org.apache.xml.security.signature.Reference - Verification
successful for URI "#Timestamp-10757386"2008-10-03 15:52:31,874
[HttpConnection-8081-1] DEBUG org.apache.axis2.context.AbstractContext
So apparently it doesn't care there, but when it goes to sign the
response I get:
(...)
2008-10-03 15:52:32,647 [HttpConnection-8081-1] DEBUG
org.apache.axis2.engine.Phase - [MessageContext:
logID=urn:uuid:A3C1E371AE4FC54EDC1223074352312] Invoking flowComplete()
in Phase "OperationOutPhase"2008-10-03 15:52:32,657
[HttpConnection-8081-1] ERROR org.apache.axis2.engine.AxisEngine -
Error in signature with X509Tokenorg.apache.axis2.AxisFault: Error in
signature with X509Token at
org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:70)
at org.apache.axis2.engine.Phase.invoke(Phase.java:317) at
org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:264) at
org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:429)
at
org.apache.rampart.builder.AsymmetricBindingBuilder.doSignBeforeEncrypt(AsymmetricBindingBuilder.java:413)
at
org.apache.rampart.builder.AsymmetricBindingBuilder.build(AsymmetricBindingBuilder.java:93)
at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:147)
at
org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:64)
... 14 more
Caused by: org.apache.ws.security.WSSecurityException: An unsupported
token was provided (An X509 certificate with version 3 must be used for
SKI. The presented cert has version: 1)
at
org.apache.ws.security.message.token.SecurityTokenReference.setKeyIdentifierSKI(SecurityTokenReference.java:272)
at
org.apache.ws.security.message.WSSecSignature.prepare(WSSecSignature.java:404)
at
org.apache.rampart.builder.BindingBuilder.getSignatureBuider(BindingBuilder.java:300)
... 19 more
Caused by: org.apache.rampart.RampartException: Error in signature with
X509Token at
org.apache.rampart.builder.BindingBuilder.getSignatureBuider(BindingBuilder.java:304)
at
org.apache.rampart.builder.AsymmetricBindingBuilder.doSignature(AsymmetricBindingBuilder.java:626)
I tried out the new axis2.war in my service which uses v3 certificates.
It worked there, but only when the complete policy was attached to the
binding element in services.xml. What I am trying to do is to have input
messages signed and time stamped and reply message just time stamped.
This was obvious in the old inflow outflow security settings, but when
using policy requires attaching the signed parts policy to the messages.
When I do that it seems to get ignored and an unsigned message is not
rejected.
I attached the policy as:
<operation name="queryReservation"
<module ref="rampart" />
<actionMapping>http://oscars.es.net/OSCARS/queryReservation
<wsp:policy wsu:id="signedMsgPolicy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy";
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>>
<sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";>
<sp:Body/>
</sp:SignedParts>
</wsp:policy>
</actionMapping>
<outputActionMapping>http://oscars.es.net/OSCARS/OSCARS/queryReservationResponse</outputActionMapping>
<faultActionMapping
faultName="AAAErrorException">http://oscars.es.net/OSCARS/OSCARS/queryReservation/Fault/AAAErrorException</faultActionMapping>
<faultActionMapping
faultName="BSSErrorException">http://oscars.es.net/OSCARS/OSCARS/queryReservation/Fault/BSSErrorException</faultActionMapping>
</operation>
I had first tried a PolicyAttachment element but that didn't work either.
BTW, I am using the Rampart nightly build with the standard axis2-1.4.1
release, so that could be a problem.
Thanks for any advice you can give me,
Mary
Nandana Mihindukulasooriya wrote:
Hi Mary,
Thanks for the reply. I was rather surprised that such a bug in
what I think is a common security protocol wouldn't have been caught
sooner. I was wondering if it was not always reproducible.
Yeah, it is too bad that we didn't catch this any sooner. I think we
might even have to think a minor release with this fix included. And we
need to strengthen the test suites in Rampart. Any help from the
community will be highly appreciated.
thanks,
nandana
Nandana Mihindukulasooriya (JIRA) wrote:
[
https://issues.apache.org/jira/browse/RAMPART-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636004#action_12636004
<https://issues.apache.org/jira/browse/RAMPART-183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636004#action_12636004>
]
Nandana Mihindukulasooriya commented on RAMPART-183:
----------------------------------------------------
Hi Mary,
Yeah, there is a bug in validation. Thanks for pointing out.
Will fix this asap and commit to the trunk.
thanks,
nandana
Rampart not correctly enforcing Signature validity if other
security elements exist (ie - Timestamp)
----------------------------------------------------------------------------------------------------
Key: RAMPART-183
URL:
https://issues.apache.org/jira/browse/RAMPART-183
Project: Rampart
Issue Type: Bug
Components: rampart-core
Affects Versions: 1.3
Environment: IBM Rational Application Developer,
Websphere 6.0 runtime on Windows XP, Unix
Reporter: Wally Dennis
Assignee: Nandana Mihindukulasooriya
It appears as though Rampart/WSS4J is not enforcing the
<InflowSecurity> settings that I have in my services.xml
file. Here are the settings as I have them configured:
<parameter name="InflowSecurity">
<action>
<items>Timestamp Signature</items>
<signaturePropFile>config/base/configuration.properties</signaturePropFile>
</action>
</parameter>
I discovered this issue during my testing - my test client
is sending in a SOAP request that contains a Timestamp but
not a Signature. This results in the creation of the
<wsse:Security> element in the SOAP header that contains
only the <wsu:Timestamp> child as shown here:
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soapenv:mustUnderstand="1">
<wsu:Timestamp
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="Timestamp-724480920">
<wsu:Created>2008-07-08T13:49:08.433Z</wsu:Created>
<wsu:Expires>2008-07-08T13:54:08.433Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
In Rampart's WSDoAllReciever class, I can see were it is
decoding the actions configured, but these actions are not
then passed into the WSSecurityEngine to indicate which
items should be validated. Therefore, the WSSecurityEngine
and subsequent classes simply use the elements in the
<wsse:Security> header to determine what to validate. This
results in the timestamp being validated correctly, but it
does not throw an error due to the lack of the
<ds:Signature> element.
One additional thing - in debugging through this, I do see
where the enableSignatureConfirmation variable in WSSConfig
is set to true, so this may be an issue with WSS4J. If I
need to submit this report under WSS4J I will.
Thanks.
--
Nandana Mihindukulasooriya
WSO2 inc.
http://nandana83.blogspot.com/
http://www.wso2.org
