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

Jason Eaton updated WSS-567:
----------------------------
    Description: 
I’m not sure why the WSS4J is not recognizing our messages. This is just 
testing the existing signature feature of our server with the new WSS4J 2.1.4. 
I’m still working on how to convince the software to expect the correct 
namespace.

The two classes that define constants relative to 1.1 or 1.2 soap 
specification, which work correctly. The software believes this is a soap 1.1 
message which is corrrrect. They are looking for the Security header element in 
the document which is present and valid.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
               xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext";>
    <soap:Header>
        <wsse:BinarySecurityToken EncodingType="wsse:Base64Binary" 
Id="X509Token" ValueType="wsse:X509v3">
            
MIICZTCCAc6gAwIBAgIWNDAzMjk4NzEyOTkxMDE3OTA4OTI3NzANBgkqhkiG9w0BAQUFADAeMRww&#13;
…            
NulsPIzixDPpgKm8iPF1i8EEz/n3ByF2dKMMfn7Q5UgvXzjYOGsqwuwBXbzlPmpdW0DN4j6l/O0+&#13;
            djYJLdB/lvvj8kv9GfwLIlId5TejGtGVqCgUa7tzsOLBj0uvZpNBELA948iRYF4=
        </wsse:BinarySecurityToken>
        <wsse:Security>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
                <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>
                    <CanonicalizationMethod 
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

But they keep comparing the envelope namespace  a different schema, where the 
below namespace which doesn’t match. So it cannot find the security header. 

public static final String WSSE_NS = 
    
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";;

I believe the problem is in the WSSecurityUtil class method, getSecurityHeader 
where they choose the 1.2 namespace.

    public static Element getSecurityHeader(Document doc, String actor) throws 
WSSecurityException {
        Element soapHeaderElement = getSOAPHeader(doc);
        if (soapHeaderElement == null) { // no SOAP header at all
            return null;
        }
        
        String soapNamespace = 
WSSecurityUtil.getSOAPNamespace(doc.getDocumentElement());
        return getSecurityHeader(soapHeaderElement, actor, 
WSConstants.URI_SOAP12_ENV.equals(soapNamespace));
    }

and in WSSecurityUtil ... WSSE_NS is the 1.2 namespace.

            if (Node.ELEMENT_NODE == currentChild.getNodeType()
                && WSConstants.WSSE_LN.equals(currentChild.getLocalName())
                && WSConstants.WSSE_NS.equals(currentChild.getNamespaceURI())) {

  was:
I’m not sure why the WSS4J is not recognizing our messages. This is just 
testing the existing signature feature of our server with the new WSS4J 2.1.4. 
I’m still working on how to convince the software to expect the correct 
namespace.

The two classes that define constants relative to 1.1 or 1.2 soap 
specification, which work correctly. The software believes this is a soap 1.1 
message which is corrrrect. They are looking for the Security header element in 
the document which is present and valid.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
               xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext";>
    <soap:Header>
        <wsse:BinarySecurityToken EncodingType="wsse:Base64Binary" 
Id="X509Token" ValueType="wsse:X509v3">
            
MIICZTCCAc6gAwIBAgIWNDAzMjk4NzEyOTkxMDE3OTA4OTI3NzANBgkqhkiG9w0BAQUFADAeMRww&#13;
…            
NulsPIzixDPpgKm8iPF1i8EEz/n3ByF2dKMMfn7Q5UgvXzjYOGsqwuwBXbzlPmpdW0DN4j6l/O0+&#13;
            djYJLdB/lvvj8kv9GfwLIlId5TejGtGVqCgUa7tzsOLBj0uvZpNBELA948iRYF4=
        </wsse:BinarySecurityToken>
        <wsse:Security>
            <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
                <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>
                    <CanonicalizationMethod 
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>

But they keep comparing the envelope namespace  a different schema, where the 
below namespace which doesn’t match. So it cannot find the security header. 

public static final String WSSE_NS = 
    
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";;

I believe the problem is in the WSSecurityUtil class method, getSecurityHeader 
where they ALWAYS choose the 1.2 namespace.

    public static Element getSecurityHeader(Document doc, String actor) throws 
WSSecurityException {
        Element soapHeaderElement = getSOAPHeader(doc);
        if (soapHeaderElement == null) { // no SOAP header at all
            return null;
        }
        
        String soapNamespace = 
WSSecurityUtil.getSOAPNamespace(doc.getDocumentElement());
        return getSecurityHeader(soapHeaderElement, actor, 
WSConstants.URI_SOAP12_ENV.equals(soapNamespace));
    }


> processSecurityHeadaers does not work for 1.1 namespace
> -------------------------------------------------------
>
>                 Key: WSS-567
>                 URL: https://issues.apache.org/jira/browse/WSS-567
>             Project: WSS4J
>          Issue Type: Bug
>          Components: WSS4J Core
>    Affects Versions: 2.1.4
>         Environment: windows 64
>            Reporter: Jason Eaton
>            Assignee: Colm O hEigeartaigh
>
> I’m not sure why the WSS4J is not recognizing our messages. This is just 
> testing the existing signature feature of our server with the new WSS4J 
> 2.1.4. I’m still working on how to convince the software to expect the 
> correct namespace.
> The two classes that define constants relative to 1.1 or 1.2 soap 
> specification, which work correctly. The software believes this is a soap 1.1 
> message which is corrrrect. They are looking for the Security header element 
> in the document which is present and valid.
> <?xml version="1.0" encoding="UTF-8"?>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
>                xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/04/secext";>
>     <soap:Header>
>         <wsse:BinarySecurityToken EncodingType="wsse:Base64Binary" 
> Id="X509Token" ValueType="wsse:X509v3">
>             
> MIICZTCCAc6gAwIBAgIWNDAzMjk4NzEyOTkxMDE3OTA4OTI3NzANBgkqhkiG9w0BAQUFADAeMRww&#13;
> …            
> NulsPIzixDPpgKm8iPF1i8EEz/n3ByF2dKMMfn7Q5UgvXzjYOGsqwuwBXbzlPmpdW0DN4j6l/O0+&#13;
>             djYJLdB/lvvj8kv9GfwLIlId5TejGtGVqCgUa7tzsOLBj0uvZpNBELA948iRYF4=
>         </wsse:BinarySecurityToken>
>         <wsse:Security>
>             <Signature xmlns="http://www.w3.org/2000/09/xmldsig#";>
>                 <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>
>                     <CanonicalizationMethod 
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> But they keep comparing the envelope namespace  a different schema, where the 
> below namespace which doesn’t match. So it cannot find the security header. 
> public static final String WSSE_NS = 
>     
> "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";;
> I believe the problem is in the WSSecurityUtil class method, 
> getSecurityHeader where they choose the 1.2 namespace.
>     public static Element getSecurityHeader(Document doc, String actor) 
> throws WSSecurityException {
>         Element soapHeaderElement = getSOAPHeader(doc);
>         if (soapHeaderElement == null) { // no SOAP header at all
>             return null;
>         }
>         
>         String soapNamespace = 
> WSSecurityUtil.getSOAPNamespace(doc.getDocumentElement());
>         return getSecurityHeader(soapHeaderElement, actor, 
> WSConstants.URI_SOAP12_ENV.equals(soapNamespace));
>     }
> and in WSSecurityUtil ... WSSE_NS is the 1.2 namespace.
>             if (Node.ELEMENT_NODE == currentChild.getNodeType()
>                 && WSConstants.WSSE_LN.equals(currentChild.getLocalName())
>                 && 
> WSConstants.WSSE_NS.equals(currentChild.getNamespaceURI())) {



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to