Return-Path: Delivered-To: apmail-ws-sandesha-dev-archive@www.apache.org Received: (qmail 67421 invoked from network); 31 Jul 2006 10:25:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 31 Jul 2006 10:25:17 -0000 Received: (qmail 19154 invoked by uid 500); 31 Jul 2006 10:25:14 -0000 Delivered-To: apmail-ws-sandesha-dev-archive@ws.apache.org Received: (qmail 19108 invoked by uid 500); 31 Jul 2006 10:25:14 -0000 Mailing-List: contact sandesha-dev-help@ws.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list sandesha-dev@ws.apache.org Received: (qmail 19083 invoked by uid 99); 31 Jul 2006 10:25:14 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 03:25:14 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of chamikaramj@gmail.com designates 64.233.184.224 as permitted sender) Received: from [64.233.184.224] (HELO wr-out-0506.google.com) (64.233.184.224) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 31 Jul 2006 03:25:13 -0700 Received: by wr-out-0506.google.com with SMTP id 70so256295wra for ; Mon, 31 Jul 2006 03:24:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YCIV/9Y5ZCUYVfxdlre7TJcToOUpgLJSGBu47yY8NritWKyHGTc1xm0hmHroC0gSHnF+I/wSwQIuDXoL+oGQtn0qu+B3UIqH4sagHItJm/QjBRTJh4xH7p8bBsZueRe6rR8reUVdbNM8JbMXxL6PEddsAL+HSYO92nstq2lMprk= Received: by 10.65.84.5 with SMTP id m5mr1640584qbl; Mon, 31 Jul 2006 03:24:39 -0700 (PDT) Received: by 10.64.250.13 with HTTP; Mon, 31 Jul 2006 03:24:39 -0700 (PDT) Message-ID: <9d4ec10b0607310324s2aaab14ane7acec6505d79d40@mail.gmail.com> Date: Mon, 31 Jul 2006 15:54:39 +0530 From: "Chamikara Jayalath" To: "Matthew Lovett" Subject: Re: RM+Security Cc: sandesha-dev@ws.apache.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4038_12826369.1154341479661" References: <88f5d710607310201x27c2409csd81a52ef4b2f1c39@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_4038_12826369.1154341479661 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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" 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 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 > > > Date: Jul 28, 2006 7:16 PM > > > Subject: Re: RM+Security > > > To: Ruchith Fernando , Matthew Lovett > > > > > > Cc: Chamikara Jayalath , Jaliya Ekanayake > > > , sandesha-dev@ws.apache.org, Sanjiva Weerawarana > > > > > > > > > > > > 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" > > > To: "Ruchith Fernando" < ruchith.fernando@gmail.com> > > > Cc: "Chamikara Jayalath" ; "Jaliya Ekanayake" > > > ; ; "Sanjiva > Weerawarana" > > > > > > 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 > > > > ------=_Part_4038_12826369.1154341479661 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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
>


------=_Part_4038_12826369.1154341479661--