[
https://issues.apache.org/jira/browse/RAMPART-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Lazarski updated RAMPART-261:
------------------------------------
Fix Version/s: 1.8.0
> Ability to Toggle "mustUnderstand" flag in security header.
> -----------------------------------------------------------
>
> Key: RAMPART-261
> URL: https://issues.apache.org/jira/browse/RAMPART-261
> Project: Rampart
> Issue Type: New Feature
> Components: rampart-core
> Affects Versions: 1.4
> Reporter: Earl D. Baugh Jr.
> Assignee: Robert Lazarski
> Priority: Minor
> Fix For: 1.8.0
>
>
> In dealing with a major telcom, I discovered that it's not possible to turn
> off the mustUnderstand security header attribute.
> This causes issues in that ALL of their web services run thru a "proxy" which
> understands security, but their back end services do NOT.
> Because of this, all messages that are sent to them must either not have the
> mustUnderstand attribute, or have it set to "0" or "false", or they simply
> fail with security violations. I've checked to see if actor/next would
> solve the problem, but the only way to get calls to work is to allow for this
> to be disabled.
> I've inquired to them about changing this behavior, and they have no plans
> nor intentions (from what I've been able to ascertain) of changing their
> architecture and moving to something that either strips off the security
> headers or can properly handle this setting. Additionally their responses
> do not have a SOAP header. That, thankfully I can currently handle with the
> axis2 ability to set KEY_RAMPART_OUT_POLICY. They apparently have numerous
> clients who can handle this, but I was not able to get any info as to what
> technology they're using. (the previous version here at my employer had a
> "very" customized / hacked set of axis1 code that added and monkeyed with
> various attributes).
> Since RAMPART does not get the options from Axis2 to handle the setting of
> ServiceClient options setProperty( WSDL2Constants.ATTRIBUTE_MUST_UNDERSTAND,
> "0" ), and can't be configured with the existing flow to sign but not set
> this value, I've been stuck.
> (signing causes a hard coded "true" to be set for this attribute)
> I would like to suggest / recommend adding some form of option to allow for
> signing, but not require the mustUnderstand attribute to be set.
> I have made a change to my local code and have a solution that works.
> In RampartMessageData.java, after line 358 : if(this.sender &&
> this.policyData != null) {
> a check that would call : secHeader.setMustUnderstand(false)
> when the option is set would solve this problem, and allow per call control
> of this behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
