[
https://issues.apache.org/jira/browse/SANDESHA2-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gatford resolved SANDESHA2-44.
-------------------------------------
Resolution: Fixed
> Sandesha contains hard-coded security properties for rampart
> ------------------------------------------------------------
>
> Key: SANDESHA2-44
> URL: https://issues.apache.org/jira/browse/SANDESHA2-44
> 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() method.
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
