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]
