ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <jnekanay...@gmail.com>
Subject Re: RM+Security
Date Mon, 31 Jul 2006 12:10:39 GMT
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" <pzfreo@gmail.com>
To: <sandesha-dev@ws.apache.org>
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 <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
> 


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