ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chamikara Jayalath" <chamikar...@gmail.com>
Subject Re: RM+Security
Date Mon, 31 Jul 2006 10:24:39 GMT
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 <MLOVETT@uk.ibm.com> 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" <pzfreo@gmail.com> 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 <chamikaramj@gmail.com> 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 <jnekanayake@gmail.com>
> > > Date: Jul 28, 2006 7:16 PM
> > > Subject: Re: RM+Security
> > > To: Ruchith Fernando <ruchith.fernando@gmail.com>, Matthew Lovett
> > > <MLOVETT@uk.ibm.com>
> > >  Cc: Chamikara Jayalath <chamikaramj@gmail.com>, Jaliya Ekanayake
> > > <jaliya@apache.org>, sandesha-dev@ws.apache.org, Sanjiva Weerawarana
> > > <sanjiva@opensource.lk>
> > >
> > >
> > > 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" <MLOVETT@uk.ibm.com>
> > > To: "Ruchith Fernando" < ruchith.fernando@gmail.com>
> > > Cc: "Chamikara Jayalath" <chamikaramj@gmail.com>; "Jaliya Ekanayake"
> > > <jaliya@apache.org >; <sandesha-dev@ws.apache.org>; "Sanjiva
> Weerawarana"
> > > <sanjiva@opensource.lk>
> > > 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" < ruchith.fernando@gmail.com> 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:
> > > sandesha-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> > > >
> > >
> > >
> >
> >
> > --
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://bloglines.com/blog/paulfremantle
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >
>
>

Mime
View raw message