You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Enda Diggins (JIRA)" <ji...@apache.org> on 2012/08/16 18:39:38 UTC
[jira] [Commented] (RAMPART-261) Ability to Toggle "mustUnderstand"
flag in security header.
[ https://issues.apache.org/jira/browse/RAMPART-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436079#comment-13436079 ]
Enda Diggins commented on RAMPART-261:
--------------------------------------
I also had this problem; resolved by patching Rampart with something similar to this feature request. I added a boolean field 'mustUnderstandSecurityHeader' to RampartConfig. Perhaps someone can suggest a better place for this? I'm happy to provide the patch if RampartConfig's the right place.
> 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.
> Priority: Minor
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org