Mailing-List: contact dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ws.apache.org
Date: Sat, 8 Jul 2017 15:43:00 +0000 (UTC)
From: "Alexandru-Constantin Bledea (JIRA)" <jira@apache.org>
To: dev@ws.apache.org
Message-ID: <JIRA.13085697.1499528381000.200072.1499528580091@Atlassian.JIRA>
In-Reply-To: <JIRA.13085697.1499528381000@Atlassian.JIRA>
References: <JIRA.13085697.1499528381000@Atlassian.JIRA> <JIRA.13085697.1499528381909@jira-lw-us.apache.org>
Subject: [jira] [Updated] (WSS-610) WSSecurityUtil.decodeAction misbehaving
 when sending NoSecurity
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 08 Jul 2017 15:43:04 -0000


     [ https://issues.apache.org/jira/browse/WSS-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexandru-Constantin Bledea updated WSS-610:
--------------------------------------------
    Description: 
The decode method from org.apache.wss4j.dom.util.WSSecurityUtil doesn't appear to do the right thing when sending NoSecurity.

If we're sending for instance "UsernameToken NoSecurity Signature" we're getting back [1]
From my point of view, it should probably return [1, 0, 2].

However, it seems like the person who wrote that code wanted NoSecurity to override any other security policy (just like org.apache.ws.security.util.WSSecurityUtil's decodeAction), in that case it should probably return just [0], but stopping at what we already parsed up to now and not including NoSecurity doesn't seem to be the correct behavior.

  was:
The decode method from WSSecurityUtil doesn't appear to do the right thing when sending NoSecurity.

If we're sending for instance "UsernameToken NoSecurity Signature" we're getting back [1]
From my point of view, it should probably return [1, 0, 2].

It seems like the person who wrote that code wanted NoSecurity to override any other security policy, in that case it should probably return just [0], but stopping at what we already parsed up to now and not including NoSecurity doesn't seem to be the correct behavior.


> WSSecurityUtil.decodeAction misbehaving when sending NoSecurity
> ---------------------------------------------------------------
>
>                 Key: WSS-610
>                 URL: https://issues.apache.org/jira/browse/WSS-610
>             Project: WSS4J
>          Issue Type: Bug
>          Components: WSS4J Core
>            Reporter: Alexandru-Constantin Bledea
>            Assignee: Colm O hEigeartaigh
>
> The decode method from org.apache.wss4j.dom.util.WSSecurityUtil doesn't appear to do the right thing when sending NoSecurity.
> If we're sending for instance "UsernameToken NoSecurity Signature" we're getting back [1]
> From my point of view, it should probably return [1, 0, 2].
> However, it seems like the person who wrote that code wanted NoSecurity to override any other security policy (just like org.apache.ws.security.util.WSSecurityUtil's decodeAction), in that case it should probably return just [0], but stopping at what we already parsed up to now and not including NoSecurity doesn't seem to be the correct behavior.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org