11.5. Does this really work?

11.5. Does this really work?
Prev	Chapter 11. Writing a Secure Math Service	Next

After all the work we've gone through to setup security, you might be a bit disappointed. After all, we've gone through all the trouble of setting up a CA and some certificates to end up writing a MathService client that behaves just like all the other MathService clients we've already seen in the tutorial. Ho hum. You're probably asking yourself: "Yeah, but is this really doing all that encryption thingy?"

To empirically prove that it is doing the 'encryption thingy', we are going to use an Apache Axis tool called TCPMonitor that is included with the toolkit. This tool allows us to intercept the data that is sent from the client to the server (and vice versa). We will see how the information is, in fact, encrypted.

To start TCPMonitor, run this:

java org.apache.axis.utils.tcpmon 8081 localhost 8080

This starts an instance of the TCPMonitor (Figure 11.1, “TCPMonitor interface (1)”). What the monitor will do is listen on port 8081 and redirect all the traffic it receives on that port to port 8080 (which is where our container is listening). This means that TCPMonitor acts like a proxy, not like a sniffer, so we'll have to tell our client to make the invocation on port 8081 to be able to see what kind of data is being sent.

Figure 11.1. TCPMonitor interface (1)


	Make sure you check the "XML Format" box in TCPMonitor. This will make reading the messages much easier.

Let's run the client again. Make sure to change '8080' for '8081' so that the invocation will go through the TCPMonitor. Otherwise, we won't be able to see it.

java \
-classpath ./build/stubs/classes/:$CLASSPATH \
org.globus.examples.clients.MathService_instance_4op.Client_GSISecConv_Encrypt \
http://127.0.0.1:8081/wsrf/services/examples/security/first/MathService

Once you've invoked the service, the TCPMonitor will reflect that it has intercepted some connections on port 8081 (Figure 11.2, “TCPMonitor interface (2)”). The top list shows a list of the connections. You can select any of them to see what was sent to the server (top text area) and what the server replied to the client (bottom text area).

Figure 11.2. TCPMonitor interface (2)

Five calls and eight connections... huh?

	Five calls and eight connections... huh?
TCPMonitor should show 8 connections. This might seem a bit odd considering that our client only makes five calls to MathService (`add`, `subtract`, `multiply`, `divide`, and `getResourceProperty`). However, remember that we're using GSI Secure Conversation. As described in the previous chapter, GSI Secure Conversation involves the creation of a security context before the client and server can actually communicate. This accounts for the first three connections. The client and server are agreeing on the details of the secure context. Once the context is created, the calls can proceed as normal.

TCPMonitor should show 8 connections. This might seem a bit odd considering that our client only makes five calls to MathService (add, subtract, multiply, divide, and getResourceProperty). However, remember that we're using GSI Secure Conversation.

As described in the previous chapter, GSI Secure Conversation involves the creation of a security context before the client and server can actually communicate. This accounts for the first three connections. The client and server are agreeing on the details of the secure context. Once the context is created, the calls can proceed as normal.

Let's take a look at the fourth connection, corresponding to the add invocation:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" 
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header>
      <wsse:Security 
        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" 
        soapenv:mustUnderstand="1">
         <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2004/04/sc" 
           xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
           wsu:Id="SecurityContextToken-15021407">
            <wsc:Identifier>8439eb60-b079-11d9-bf45-98ad001497de</wsc:Identifier>
         </wsc:SecurityContextToken>
         <xenc:ReferenceList>
            <xenc:DataReference URI="#EncDataId-749304"></xenc:DataReference>
         </xenc:ReferenceList>
      </wsse:Security>
      <wsa:MessageID soapenv:mustUnderstand="0">uuid:837bf290-b079-11d9-a882-a1d8507fabe7</wsa:MessageID>
      <wsa:To soapenv:mustUnderstand="0">
        http://127.0.0.1:8081/wsrf/services/examples/security/first/MathService
      </wsa:To>
      <wsa:Action soapenv:mustUnderstand="0">
        http://www.globus.org/namespaces/examples/core/MathService_instance_4op/MathPortType/addRequest
      </wsa:Action>
      <wsa:From soapenv:mustUnderstand="0">
         <wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous</wsa:Address>
      </wsa:From>
   </soapenv:Header>
   
   <soapenv:Body>
      <xenc:EncryptedData Id="EncDataId-749304" Type="http://www.w3.org/2001/04/xmlenc#Content">
         <xenc:EncryptionMethod Algorithm="http://www.globus.org/2002/04/xmlenc#gssapi-enc"></xenc:EncryptionMethod>
         <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <wsse:SecurityTokenReference 
              xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
               <wsse:Reference URI="#SecurityContextToken-15021407"></wsse:Reference>
            </wsse:SecurityTokenReference>
         </ds:KeyInfo>
         <xenc:CipherData>
            <xenc:CipherValue>
            FwMAAYCNYHoPTT6WgG096yj0NPONpNXp3u8tVPbPBjZzqzFtx03Yh1tMEI6ebObR1Rvr8ihBk+EtBsCAUNuVXN7QAP/FrMIZJ
            zacALBaLpie0A1BfO8QjjDNGvv6KsDrydY2qywSuaZvqclUus2eAnPjW3ewanPqemntYfSHKW0X81wkIDI4oUx5WOOkYbKLl6
            Yg/R4osS2PR+/aqAwAb8vdZtzDdBkpyIDfCsMrQnZA1sarFbdZPT7buNIPRJ8vja3/icV5yB4WZg8sobm7K7yrYkFT6g1nLHh
            gznsJj0pf67BcowXO+swp0uSAnjczNEyDRafk6HaIPeeMpZWLGNL11BrfHM1pDGs0foDCvbFApfFJGz5v70DdAGQWz5xsR6YQ
            0Bp8gc0hlB+hrsc6Wyf8RiQ/kxBfMYZ3hKY8fah4oRaq39/sJvA8pXnfxvp1EKonQKhOh/yYYGkuzMI4whD0KsLAiEwjX3uOh
            UdAF1zwwqyPK4zYBHsz1Qe0I8lD2OmTjQw=
            </xenc:CipherValue>
         </xenc:CipherData>
      </xenc:EncryptedData>
   </soapenv:Body>
   
</soapenv:Envelope>

Holy gibberish, Batman! :-)

Notice how only certain parts of the message are encrypted, not the whole message. Remember that this is because GSI Secure Conversation is a form of message-level security (explained in Section 10.2, “Transport-level and message-level security”). This means that we only encrypt the contents of the message, but not the whole message. Notice how the message still reveals what the service URI is, along with the operation name, but the actual call itself is encrypted. If we wanted the whole message to be encrypted we would need to use transport-level security (GSI Transport).

Prev	Up	Next
11.4. Trying it out	Home	Part IV. GT4 Information Services [Coming soon]