ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <pzf...@gmail.com>
Subject Fwd: RM+Security
Date Mon, 31 Jul 2006 10:34:22 GMT
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 <chamikaramj@gmail.com> 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 <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
> > >
> >
> >
>
>


--
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


-- 
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