I don't think the latest spec should say that anymore. I don't know how Rampart and WSS4J manage the length of a security session anyway.
So as to Jaliya's point, maybe there needs to be a notification system for other MARs..... that a security session is about to be closed. Then the RM sequence manager could request it to stay open until the sequence is properly terminated. Paul On 7/31/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote:
Hi Jaliya, Matt, All, The RM Spec says "Security contexts are independent of reliable messaging Sequences. Consequently, security contexts can come and go independent of the lifetime of the Sequence. In fact, it is recommended that the lifetime of a security context be less than the lifetime of the Sequence unless the Sequence is very short-lived." So it seems like Jaliya's point is correct. Matt, can we do some changes to ur patch and provide this. Chamikara ---------- Forwarded message ---------- From: Jaliya Ekanayake <[EMAIL PROTECTED]> Date: Jul 28, 2006 7:16 PM Subject: Re: RM+Security To: Ruchith Fernando <[EMAIL PROTECTED]>, Matthew Lovett <[EMAIL PROTECTED]> Cc: Chamikara Jayalath <[EMAIL PROTECTED]>, Jaliya Ekanayake <[EMAIL PROTECTED]>, [email protected], Sanjiva Weerawarana <[EMAIL PROTECTED]> Hi Matt, Could you please explain how can we handle long running RM sequences with multiple SecurityTokens from the way you have suggested? Thanks, -Jaliya ----- Original Message ----- From: "Matthew Lovett" <[EMAIL PROTECTED]> To: "Ruchith Fernando" < [EMAIL PROTECTED]> Cc: "Chamikara Jayalath" <[EMAIL PROTECTED]>; "Jaliya Ekanayake" <[EMAIL PROTECTED] >; <[email protected]>; "Sanjiva Weerawarana" <[EMAIL PROTECTED]> Sent: Friday, July 28, 2006 8:08 AM Subject: Re: RM+Security > Hi all, > > Thanks for your time, we seem to be having a useful discussion here. > > "Ruchith Fernando" < [EMAIL PROTECTED]> wrote on 28/07/2006 > 12:29:03: > >> Hi Matt, >> >> Yes ... I agree with this flow. >> >> But I was wondering why it is necessary to sandesha to add the >> placeholder since anyway the security module will have to be aware of >> the CreateSequence message? >> > I don't think that the security layer should be aware of the create > sequence, and this design doesn't require it to. > >> For example the security module will have to block a create seqence >> message and will have to establish a SecConv context and add the STR >> in the CreateSeq msg to point to the SecConv context that was >> established. At this point we can use the message context to share the >> toke info with sandesha. > > No, you create the SecConv context when I ask you for a token. If you go > and get it right away then there is no need to interrupt the create > sequence as it passes through the security handlers. > >> >> In this case all the information for the STR is with the security >> module. Therefore why do we need the placeholder? >> >> Thanks, >> Ruchith >> > > The point of the placeholder is that it tries to allow the security module > to compose with RM without requiring the security layer to provide special > processing for RM messages. If we follow this approach, then other WS-* > specs that take a similar approach to security can be implemented without > change in the security module. My security team are more inclined to go > for the more general approach, and don't want to put special RM handling > into their code. After all, what if sandesha is not even engaged, or > applied to the current message? You are doing processing that could be > bypassed completely. > > Of course, if the group really wants to do it your way then I can fix it > up by adding another IBM handler after sandesha and before security - and > I can emulate the processing you describe there. I'd just rather not ;) > > Cheers, > > Matt > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
