[
https://issues.apache.org/jira/browse/WSS-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609684#action_12609684
]
Fred Dushin commented on WSS-131:
---------------------------------
Hi Lisa,
Could you be a bit more specific about the shortcomings of WSS4J here? Is this
a specific issue with the way WSS4J is integrated with Axis or other
middleware, or is it an issue with the WSS4J APIs?
We've actually had a very similar issue reported (WSS-130), which has more to
do with the processing of the receiver results after the "core" WSS4J
processing logic is completed.
I'm inclined to move this ticket to the "WSS4J Handler" component, since the
core WSS4J code (my terminology here) will ignore headers it doesn't know
about, but I'd like to know more about what the exact issue is.
Thanks!
> 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]
