axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enda Diggins (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (RAMPART-261) Ability to Toggle "mustUnderstand" flag in security header.
Date Thu, 16 Aug 2012 16:39:38 GMT

    [ 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


Mime
View raw message