Re: [wss-dev] SOAP Message Security 1.1 Implementation

[Richard Salz <rsalz@us.ibm.com>]

> - It looks like in order to implement SignatureConfirmation as 
> defined in the spec one has to maintain persistency. Is there a way 
> to workaround persistency for that case?

One thing you could do is that for every signature you could output a 
confirmation element all the time (or perhaps depending on some (global) 
flag).  But no, someobody, somewhere, has to have the original signature 
(and state) so that it can be confirmed.

> - The standard relates to parsing of multiple Security headers by 
> the same actor as ambiguous - it considers the order in which they 
> are parsed is undefined. If I want to serve many clients that I 
> didn't priorly agree on the Security headers parsing order, what 
> would you suggest?

The order in which they appear in the SOAP envelope.

> - Can somebody recommend on an open-source/free library of 
> encryption/encoding/digest algorithms that will fit the requirements
> of SOAP Message Security spec, XML Digital Signatures spec, and XML 
> Encryption spec (sha1, base64, etc etc..).

There are several.  For Java there's the Apache security library. For 
C/C++ there's xmlsec which is built on libxml and OpenSSL.  If you want 
just crypto there's also Wei Dai's crypto++ library.  All of this brings 
up the questions what you are implementing in, and why?

> - Would you recommend returning a fault-message for an error, such 
> as invalid key, or just reject the message without sending any fault
> message. I have read recommendations for not returning a value, in 
> order to mitigate cases of DoS.

It depends on what your library does. If you are not doing the full soap 
stack, then just return an error condition back to your caller.  Perhaps 
provide a routine that will return a formatted fault message.  The 
recommendations you read make no sense -- they've already gotten you to do 
all the work, hence subjected you to DoS; what you return, if anything, 
doiesnt matter.

> - All "any" attributes and elements specified in the SOAP Message 
> Security 1.1 Spec, for example /wsse:Security/@{any} and /wsse:
> Security/{any} specify the following  - "Unrecognized elements 
> SHOULD cause a fault.". Would you recommend rejecting the message in
> such case as schema invalid? What would be the concern in such case?

No, they are not schema-invalid.  There issue is that if a sender puts 
unknown elements directly inside a WSSE header, there could be security 
implications that the receiver does not understand. It's hard to imagine a 
real-world example. Suppose a sender generates a message that has an 
"expiration" value, saying that the crednetials should be completely 
ignored in 20 days.  The obvious way to do that is with something like 
wsse:Security/tns:Expiration. If the receiver doesn't understand this 
header and processes the header a month from now ...  But do note that 
it's a SHOULD not a MUST.

Hope this helps.

        /r$

--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/



> 
> Thanks,
> Jason