+1 ... lets get these changes in. Thanks, Ruchith
On 7/31/06, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
Yes, Let's get this model working. We can handle the case of long running sequences (if at all required) using the way Matt has explained. -Jaliya ----- Original Message ----- From: "Paul Fremantle" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Monday, July 31, 2006 6:34 AM Subject: Fwd: RM+Security > Sounds like a good plan Matt. > > By the way, I'm not sure we need to worry about the token expiration > just yet. My understanding is that tokens should last 24 hours-ish. > Obviously once we've got this all working nicely we can tweak it for > the long-running case, but the main thing is to get it working for the > 95% case. > > Paul > > > > On 7/31/06, Chamikara Jayalath <[EMAIL PROTECTED]> wrote: >> Hi Matt, >> >> Good idea. Could u send a new patch. Old one cant be applied due to some >> commits i did :-( >> >> Chamikara >> >> >> >> On 7/31/06, Matthew Lovett <[EMAIL PROTECTED]> wrote: >> > Hi all, >> > >> > I'm not 100% sure of the right way to go with this one. On one hand, >> > the >> > SecurityToken object that the security manager gives to the Sandesha >> > layer >> > is basically opaque, so if the security layer wants to use it to map to >> > a >> > series of 'real' short-lived tokens then that would be ok. Of course, >> > if >> > you are doing that then you'd need to have a fairly sophisticated >> > checkProofOfPossesion method to work out if the tokens used in the >> > message >> > are acceptable. I think this can work ok for the case where you use a >> > series of (quite short lived) keys derived from an initial (long lived) >> > key. >> > >> > On the other hand, I think Paul may be right too. If the security token >> > expires, the RM layer is all out of luck. Perhaps it's nice to give it >> > a >> > warning that this is about to happen (at few minutes early?) and let it >> > clean up as best it can. That, or add a "willExpireSoon()" method to >> > SecurityToken. >> > >> > It would help me out quite a lot if we could get the current code into >> > the >> > codebase. I think that the current state of play is that I should >> > restructure the SecurityManager to pass OMElements around instead of >> > assuming anything about the STR. I'll try and do that today, and if I >> > do >> > I'd really appreciate it if we could check it in. We can improve things >> > later. Sound ok? >> > >> > Thanks >> > >> > Matt >> > >> > "Paul Fremantle" < [EMAIL PROTECTED]> wrote on 31/07/2006 10:01:27: >> > >> > > 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] >> > > >> > >> > >> >> > > > -- > 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 > > > -- > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- www.ruchith.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
