ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Gatford (JIRA)" <>
Subject [jira] Resolved: (SANDESHA2-44) Sandesha contains hard-coded security properties for rampart
Date Thu, 29 Nov 2007 11:13:43 GMT


Andrew Gatford resolved SANDESHA2-44.

    Resolution: Fixed

> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>                 Key: SANDESHA2-44
>                 URL:
>             Project: Sandesha2
>          Issue Type: Improvement
>            Reporter: Matt Lovett
>            Priority: Minor
>         Attachments: rampart.patch
> Within SandeshaUtil::createNewRelatedMessageContext() we copy over 2 properties that
were added to help the RampartBasedSecurityManager. I think that we can probably remove these
hard coded dependencies. My suggestion to move this along is to:
> 1. In RMMsgCreator, where we currently pass the context that will carry the create sequence
message into SecurityManager::getSecurityToken(), pass in the application message context
instead. This context is much more likely to have the right config associated with it. (This
may remove the need to copy the properties over altogether.)
> 2. If the former is not enough, then the RampartBasedSecurity manager needs to read the
values of the properties at the time we call getSecurityToken(), and store them into the RampartSecurityToken
instance. The values can then be added to each outbound message during the RampartBasedSecurityManager::applySecurityToken()
> I'm happy to do part 1 (I have a patch in my workspace), but I'm not sure how to test
this. If I put the patch up could someone who uses Rampart take a look, and tell me if we
need part 2?
> Thanks
> Matt

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message