Hans, Could you please help with some info on updating to WSS 1.1? Werner, i've checked in the latest docs in the specs directory.
thanks, dims On 5/6/05, Werner Dittmann <[EMAIL PROTECTED]> wrote: > Dims, > > I started to dig into the SignatureConfirmation stuff. As usual some > points are not > clear to me, also after looking into the examples of the interop docs > you sent me. > > Maybe you can forward the question the the WSS group. > > In the SOAP Message security document, dated Feb, 14th the relevant part for > the SignatureConfirmation reads in section "response generation rules": > > <quote> > every response message generated, the responder MUST include a > <wsse11:SignatureConfirmation> element for every <ds:Signature> element it > processed from the original request message. The Value attribute MUST be > set to the exact > value of the <ds:SignatureValue> element of the corresponding > <ds:Signature> element. > </quote> > > If the request contains just _one_ ds:Signature then it is easy, but how > is the > correlation done if the request contains more than one ds:Signature? The > responder > can insert the the SignatureConfirmation elements for each ds:Signature > it sees. > But how does the the initiator (receiver of the response) now correlates > both? > > I don't see any Id mechanism in the spec that supports such a correlation on > the initiator side. Or is the correlation done implicitly via the order > of ds:Signature > in the request, i.e. the responder must insert SignatureConfirmation in > the same > order as it processed the ds:Signature? IMHO this would be complicated > to implement > and is inherently unsafe. Another way could be that the initiator loops > over all > SignatureConfirmation and checks if it generated a corresponding > ds:Signature - well, > IMHO not a good way either. > > Also the interop docs you sent me didn't help a lot (at least not for > me). Looking at the > example response message in chapter 3.3 I just see the > SignatureConfirmation element, > but not how it directly relates to the security request message shown in > chapter 3.2 except > for the fact that the request contains one ds:Signature only. > > BTW, the examples themselves are somewhat confusing as they use the same > SignatureValues for both the request and the response - this is > confusing at the > first look because this _should_ never happen. I know, its just an > example, but .... > > Regards, > Werner > > Davanum Srinivas schrieb: > > >Sounds tough...Here is the interop doc. It's basically > >SecureConversation + ReliableMessaging. > > > >thanks, > >-- dims > > > >On 4/12/05, Dittmann Werner <[EMAIL PROTECTED]> wrote: > > > > > >>Dims, > >> > >>just looked at the specs (was the first time I saw it because > >>I don't check the OASIS WS site regularly). > >> > >>Unfortunatly it's not so easy to implement it to conform to > >>the specs. > >> > >>Reasons: > >> > >>WSS4J needs to correlate the request and the response data > >>on both sides (sender and receiver). To do that we need to > >>introduce some handshake data in the message context(probably > >>using a property) of the Axis message. > >> > >>Both parts of the handler (the receiver and the sender) must > >>be extended to support this. Also the WSS4J library code > >>must be extended. Currently neither the WSSecurityEngine nor > >>the Signature generating parts of WSS4J (WSSigneEnvelope) deal > >>in an way with the Signature value directly. > >> > >>To conform to the specs we need to get this value and store > >>it in the "handshake" data. This must be done when generating > >>a Signature (sending a request) and during Verification > >>(receiving a request). Thus WSSecurityEnging and WSSignEnvelope > >>must be enhanced to return the Signature value to the handler. > >> > >>When generating the response the handler must retrieve the > >>handshake data (Signature Value) gathered during verification > >>and insert it into the response signature to be generated. This > >>is an additional enhancement of WSSignEnvelope. > >> > >>We need to enhance the receivier part of the handler to cope > >>with the required checks. The receiver must get the > >>SignatureConfirmation data from the resopnse and compare it with > >>the Signature value generated during request signing. This requires > >>an enhancement of the handler as well as of WSSecurityEngine to > >>get the new SignatureConfirmation element and return it to the handler. > >> > >>Then we need to extend the handler to accept new control > >>parameters to drive the SignatureConfirmation behaviour. > >> > >>Well, if time permits I may be able to start an implementation > >>during the next weekend - currently I'm on a business trip. > >>Are there any interop specs available? > >> > >>Regards, > >>Werner > >> > >> > >> > >>>-----Ursprüngliche Nachricht----- > >>>Von: Davanum Srinivas [mailto:[EMAIL PROTECTED] > >>>Gesendet: Dienstag, 12. April 2005 04:44 > >>>An: Dittmann Werner; Werner Dittmann > >>>Betreff: SignatureConfirmation > >>> > >>> > >>>Werner, > >>> > >>>Do you think it is easy to add SignatureConfirmation (as mentioned in > >>>this OASIS WS-Security 1.1 draft). We (Apache) are trying to go to an > >>>Interop workshop for SecureConversation + ReliableMessaging and folks > >>>there are pushing us to implement this thingy. unfortunately there is > >>>VERY little time. Interop is on 13,14,15th :( > >>> > >>>Please see enclosed PDF and the links below. > >>> > >>>Thanks, > >>>-- dims > >>> > >>>http://lists.oasis-open.org/archives/wss/200408/msg00059.html > >>>http://lists.oasis-open.org/archives/wss/200408/doc00002.doc > >>>-- > >>>Davanum Srinivas - http://webservices.apache.org/~dims/ > >>> > >>> > >>> > > > > > > > > > > -- Davanum Srinivas -http://blogs.cocoondev.org/dims/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
