Announcement Announcement Module
Collapse
No announcement yet.
payload mapping and token security? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • payload mapping and token security?

    Here's perhaps a silly question.

    I have a webservice that was based on the PayloadRootQNameEndpointMapping. It worked.

    I then wanted to add a requirement for a security token to it, so I added all the config stuff.

    Doing so seems to work because I can see this logged:

    2006-09-19 14:08:03,169 WARN [org.springframework.ws.soap.security.xwss.XwsSecur ityInterceptor] - Could not validate request: com.sun.xml.wss.XWSSecurityException: Message does not conform to configured policy [ AuthenticationTokenPolicy(S) ]: No Security Header found; nested exception is ...

    when I call the web service from web service explorer (no security token)

    but then when I call it from a .net client I have that adds the security token, it validates against the security information:

    2006-09-19 14:08:03,185 DEBUG [org.springframework.ws.soap.SoapMessageDispatcher] - MessageDispatcher with name 'messageDispatcher' sends response [org.springframework.ws.soap.saaj.SaajSoapMessage@1 080876]
    2006-09-19 14:08:29,336 DEBUG [org.springframework.ws.soap.SoapMessageDispatcher] - MessageDispatcher with name 'messageDispatcher' received request [org.springframework.ws.soap.saaj.SaajSoapMessage@1 762fc7]
    2006-09-19 14:08:29,367 DEBUG [org.springframework.ws.endpoint.mapping.PayloadRoo tQNameEndpointMapping] - Looking up endpoint for [{http://www.w3.org/2001/04/xmlenc#}EncryptedData]

    Is it not possible to use a payload mapping with a security token?

  • #2
    Originally posted by farrellr View Post
    Is it not possible to use a payload mapping with a security token?
    No, you cannot use the payload mapping with a encrypted message. This is basically due to the fact that interception is done after the mapping. So, when the mapping occurs, the payload is still encrypted. This means the encrypted qname of the payload does not map to any values defined in your configuration.

    Instead, you can use the SOAP Action mapping.

    Comment


    • #3
      Thanks Arjen

      That makes sense - I had already switched to soap action but it's good to know for sure.
      Thanks.

      Comment


      • #4
        still can't get security working correctly...

        I have an issue I don't understand trying to use security with SoapActionEndpointMapping. My endpoint works without security.
        When I add SimplePasswordValidationCallbackHandler it seems to prohibit the endpoint if I don't call it with the correct username and password. When I do call it with the correct username and password however, I get
        ... Could not validate request: java.lang.NullPointerException;
        ...

        my endpoint works and returns the result when my bean looks like this (security commented out):
        Code:
          <bean id="secureMapping" class="org.springframework.ws.soap.endpoint.mapping.SoapActionEndpointMapping">
           	<property name="mappings">
           	<props>
         	<prop key="http://www.uptodate.com/topicRetrieve">
        		topicRetrieveEndpoint
        	</prop>
        	</props>
           	</property>
         <!--  	<property name="interceptors">
           	<list>
           	<bean class="org.springframework.ws.soap.endpoint.interceptor.SoapEnvelopeLoggingInterceptor"/>
           	<ref local="wsSecurityInterceptor"/>
           	</list>
           	</property>
           		-->
           	</bean>
        However when I uncomment the interceptors property info my logging works, and it seems the security interceptor kicks in.

        That bean looks like this:
        Code:
           <bean id="wsSecurityInterceptor"
                class="org.springframework.ws.soap.security.xwss.XwsSecurityInterceptor">
                <property name="policyConfiguration" value="classpath:securityPolicy.xml"/>
                <property name="secureResponse" value="false" />
                <property name="callbackHandlers">
                <list>
                    <ref bean="passwordValidationHandler" />
                </list>
                </property>
            </bean>
        with the passwordValidationHandler (for simple testing) defined as
        Code:
        		
        	<bean id="passwordValidationHandler" 
            	class="org.springframework.ws.soap.security.xwss.callback.SimplePasswordValidationCallbackHandler">
            	<property name="users">
                <props>
                    <prop key="Bert">Ernie</prop>
                </props>
            	</property>
        	</bean>
        If I call my web service with the username Bert and an incorrect password, I get
        "SEVERE: WSS1408: UsernameToken Authentication Failed"
        which seems correct.
        If I then change my username and password to be correct, I get the following error:

        ...<SOAP-ENV:Fault><faultcode>SOAP-ENV:Client</faultcode><faultstring xml:lang="en">java.lang.NullPointerException; nested exception is com.sun.xml.wss.XWSSecurityException: java.lang.NullPointerException</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>


        Can anyone help me understand what I should look at to fix this?
        Thanks ... Rich

        Comment


        • #5
          Can you look in your log and post the complete stack trace (if any)?

          Comment


          • #6
            mylog

            attched is the log.
            When I'm using the validatingInterceptor I can set validateRequest to false.
            It looks like when I use wsSecurityInterceptor it tries to validate always (I'm not sure against what).

            The second attachment here (more) is the output from a java client trying to call this web service as well (client based on frequent flyer client modified).
            Last edited by farrellr; Sep 22nd, 2006, 03:45 PM. Reason: add an attachment when trying from a java client now

            Comment


            • #7
              I've looked into the logs, but I'm afraid there isn't much in there I can use. The XWSS code obviously has a NPE somewhere, but it's hard to figure out where. Perhaps you can use a debugger to figure this out?

              With regard to the validation of encrypted messages: if you put the validating interceptor after the security interceptor in your app context, the message will be validated according to the schema. The interceptors are executed in order, so first the security interceptor decrypts the message, after which it is validated. The reverse order is used for responses.

              Comment


              • #8
                Thanks again Arjen

                Thanks for looking into this Arjen. I'll switch the order of the interceptors, and I'll keep testing the xwss stuff.
                ... Rich

                Comment


                • #9
                  differenc es in xml?

                  While trying to debug my issues with xwss and spring-ws, I've simplified my web service call for testing. At the moment I have a service written using spring-ws. I also have a client written with spring-ws, and I have use of the web services explorer in eclipse. I'm simply trying to pass in my request without encryption to start (passing a topicId), and see what is going on.

                  When I test with the web services explorer, my service works. When I test from my client, I get an error because my request Object doesn't seem to have the topicId value.
                  Here are the 2 dumps of the xml:

                  First, from web service explorer:
                  INFO: ==== Received Message Start ====
                  <?xml version="1.0" encoding="UTF-8"?>
                  <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:q0="http://mycom.com/merged" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                  <soapenv:Body>
                  <q0:topicRetrieveRequest>
                  <topicId>1</topicId>
                  </q0:topicRetrieveRequest>
                  </soapenv:Body>
                  </soapenv:Envelope>
                  ==== Received Message End ====

                  second from my spring-ws client:

                  INFO: ==== Received Message Start ====
                  <?xml version="1.0" encoding="UTF-8"?>
                  <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
                  <SOAP-ENV:Header/>
                  <SOAP-ENV:Body>
                  <q0:topicRetrieveRequest xmlns:q0="http://mycom.com/merged">
                  <q0:topicId>5</q0:topicId>
                  </q0:topicRetrieveRequest>
                  </SOAP-ENV:Body>
                  </SOAP-ENV:Envelope>
                  ==== Received Message End ====


                  Clearly they are different, but they seem comparable for the purposes of passing topicId. I would expect that for the explorer version there is no need to specifiy the namespace of topicId because it is inherited from topicRetrieveRequest.
                  For the spring-ws version, it is qualified with a namespace. Any idea what is wrong here?
                  Thanks for the help.
                  .. Rich

                  Comment


                  • #10
                    Possible cause of NullPointerException with XWSS

                    It may not be related, but I ran into an annoying NPE when I first started playing with Spring-WS and XWSS. Mine turned out to be caused by Axis 1.4, but it was a pain to dig out (and solved by switching the server to Axis 2). Here's the culprit from Axis 1.4's org.apache.message.MessageElement:

                    Code:
                    /**
                     * @see org.w3c.dom.Element#getAttributeNS(String, String)
                     * @deprecated not implemented!
                     * @param namespace namespace
                     * @param localName local name
                     * @return null
                     */
                    public Attr getAttributeNodeNS(String namespace, String localName) {
                        return null;  //TODO: Fix this for SAAJ 1.2 Implementation
                    }
                    This method was invoked by the reference implementation of XML Digital Signatures, but it may be used by other folks. It's the Axis 1.4 implementation of javax.xml.soap.SOAPElement.

                    Comment


                    • #11
                      thanks for the message

                      Good to know. I'm still investigating but it might be namespace related.
                      Thanks again

                      Comment


                      • #12
                        Originally posted by farrellr View Post
                        Code:
                        <q0:topicRetrieveRequest>
                          <topicId>1</topicId>
                        </q0:topicRetrieveRequest>
                        I would expect that for the explorer version there is no need to specifiy the namespace of topicId because it is inherited from topicRetrieveRequest.
                        Prefixed namespaces aren't inherited. The <topicId> element is in a different namespace than it's parent element. Inheritence (at least in the text representation) could occur in the following (no prefix):
                        Code:
                        <topicRetrieveRequest xmlns="http://mycom.com/merged">
                          <topicId>1</topicId>
                        <topicRetrieveRequest>
                        Basically, it looks like the explorer version is wrong, despite the fact that your service "works" Maybe no validation is occurring?

                        Comment


                        • #13
                          thanks again

                          Your reply is helpful. I had expected the prefixed version to perform like the non prefixed example regarding inheritance, thanks for the clarification.
                          It is true I'm not validating - I had turned it off as I simplified (removing security tokens etc) to try to get something simple working before I made things more complicated. Perhaps I should have left validation on.

                          Comment

                          Working...
                          X