[
https://issues.apache.org/jira/browse/WSS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609927#action_12609927
]
Fred Dushin commented on WSS-131:
---------------------------------
Okay, this is definitely an issue with the use of the WSS4J actions. I'm
judging from the code you posted that this is either a CXF or XFire application
that's using WSS4J, so those stacks are also partially responsible for how they
use WSS4J actions (or that they use them, at all). Note that in general you
can use WSS4J without the WSS4J handler and action APIs, so you may want to
raise a discussion on the CXF or XFire lists about their (our?) use of these
APIs.
We can also work on this end to make the handler architecture more amenable to
custom headers, as this is clearly an issue with the way handlers and actions
work. Note also that there was some work in 1.5.4 to make actions replaceable,
but more needs to be done here, to make them fully generic, in the way that
processors are, on the receiving side.
> no support for extension of SecurityHeader
> ------------------------------------------
>
> Key: WSS-131
> URL: https://issues.apache.org/jira/browse/WSS-131
> Project: WSS4J
> Issue Type: Bug
> Components: WSS4J Core
> Affects Versions: 1.5.4
> Reporter: Lisa Penninger
> Assignee: Ruchith Udayanga Fernando
>
> The WSS SecurityHeader schema definition is extensible to allow different
> types of security information to be included, i.e., I could define a FooToken
> in my schema and include it in the SecurityHeader in addition to my
> UsernameToken. However, wss4j seems to actively prevent this, throwing an
> exception if an unrecognized token is found.
--
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]
