[
https://issues.apache.org/jira/browse/RAMPART-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Leonard updated RAMPART-73:
----------------------------------
Attachment: subclass.patch
This patch allows RampartEngine subclasses to specify their own validators,
including a subclass of PolicyBasedResultsValidator, and allows subclasses of
RampartReceiver to use their own implementations of RampartEngine.
It does not fix the problem with the hard-coded module name.
> Rampart hard-codes the module name, and so can't be extended
> ------------------------------------------------------------
>
> Key: RAMPART-73
> URL: https://issues.apache.org/jira/browse/RAMPART-73
> Project: Rampart
> Issue Type: Bug
> Components: rampart-core
> Environment: Subversion revision 564197
> Reporter: Thomas Leonard
> Attachments: subclass.patch
>
>
> The Rampart code suggests that some methods can be overridden in subclasses
> (for example, PolicyBasedResultsValidator.verifyTrust).
> Therefore, I have created my own Axis 2 module subclassing Rampart, and
> specified the same handlers in my module.xml. However, no security processing
> is now performed because Rampart checks that its own name is
> WSSHandlerConstants.SECURITY_MODULE_NAME ("rampart") at the start of certain
> key methods, e.g. in RampartSender:
> public InvocationResponse invoke(MessageContext msgContext) throws
> AxisFault {
>
> if (!msgContext.isEngaged(WSSHandlerConstants.SECURITY_MODULE_NAME)) {
> return InvocationResponse.CONTINUE;
> }
> What are these checks for? Surely Axis 2 won't invoke a non-engaged handler
> anyway?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
