Hi Matt,
On 7/28/06, Matthew Lovett <[EMAIL PROTECTED]> wrote:
Hi all,
Thanks for your time, we seem to be having a useful discussion here.
"Ruchith Fernando" <[EMAIL PROTECTED]> 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.
Understood. Thanks for the clarification.
The way Rampart carries out SecConv now is that it blocks the requests
that it receives (to be secured) until it establishes the security
context. I was trying to fit the message flow into this. Hence my
earlier concerns.
If I understood correct you in the SecConv case you establish the
SecConv context in the following method:
SecurityToken t = SecurityManager::getSecurityToken(createSeqContext)
I do agree providing a way to establish the SCT here in the case of
SecConv, will be useful for future WS-* use as well.
I'm cool with this approach. :-)
Sandesha devs:
Shall we drop SecurityManager impl based on Rampart in Sandesha2 it
self? Otherwise if we try to do this in Rampart (which is inside Axis2
as a maven module) we will have to add a Sandesha2 dependency to
Axis2.
Thanks,
Ruchith
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
