ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaliya Ekanayake" <>
Subject Re: RM+Security
Date Fri, 28 Jul 2006 13:46:25 GMT
Hi Matt,

Could you please explain how can we handle long running RM sequences with 
multiple SecurityTokens from the way you have suggested?


----- Original Message ----- 
From: "Matthew Lovett" <>
To: "Ruchith Fernando" <>
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" <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message