[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wss-dev] SOAP Message Security 1.1 Implementation
> - It looks like in order to implement SignatureConfirmation asOne thing you could do is that for every signature you could output a
> defined in the spec one has to maintain persistency. Is there a way
> to workaround persistency for that case?
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 order in which they appear in the SOAP envelope.
> - 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?
There are several. For Java there's the Apache security library. For
> - 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..).
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?
It depends on what your library does. If you are not doing the full soap
> - 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.
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.
No, they are not schema-invalid. There issue is that if a sender puts
> - 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?
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]