ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <jsn...@lemoorenet.com>
Subject RE: SecureSoap (was SSLSoap) Part3 of 3.
Date Mon, 04 Sep 2000 16:41:49 GMT
George,

I haven't taken a look at this yet, but I'm interested in knowing more about
how you are doing the PKI security.  Are you planning to use 100% transport
layer security, or are you rolling security into extended SOAP headers?  If
so, what exactly is this going to look like?

I've been doing some thinking about this for a while and am close to
proposing a draft SOAP-SECURITY proposal that covers authentication, message
integrity and privacy issues.  Each of these deal with extensions to the
SOAP envelope itself, rather than relying on security built into the
transport mechanism.

Here's the gist of what I'm thinking:

  A. Authentication
     1. Basic Authentication (Level 1): Implemented as a single SOAP Header
containing the login ID and password encoded as a Base64 string

     <SOAP:Envelope>
         <SOAP:Header>
             <SOAP-SEC:authenticate mustUnderstand='1'>
                 akj4499sdl23-00=
             </SOAP-SEC>
         </SOAP:Header>
         <SOAP:Body>
             <...>
         </SOAP:Body>
     </SOAP:Envelope>

     2. Challenge-Response (Level 2): Implemented as a short series of SOAP
Requests aimed at creating a logon-session between the client and server.

        * First, the client notifies the server (via a standard SOAP
request) that it wishes to gain access.
        * Second, the server issues a challenge to the client.  The
challenge requires the client to properly encrypt a randomly generated
sequence of bytes.
        * Third, once the server verifies that the client has properly
encrypted the bytes, a session ID is issued.  The session ID is transmitted
back and forth between the client and the server and is only valid for X
amount of time.  Once the session timeout period has elapsed, the client and
server must perform the logon handshake process again.

     3. Digital Certificates (Level 3).  Based around the XML Digital
Signature specification, the client embeds their digital certificate in the
SOAP Headers and transmits their request to the server.

  B. Message Integrity.  Basic just a full implementation of the XML Digital
Signature specification.  The body of the SOAP request is signed and the
signature is embedded in the SOAP Headers.

  C. Privacy.  Element-wise encryption of select portions of the SOAP Body.



Please, let me know your thoughts.

- James


-----Original Message-----
From: George I Matkovits [mailto:matkovitsg@uswest.net]
Sent: Sunday, September 03, 2000 10:39 PM
To: soap-dev@xml.apache.org
Subject: SecureSoap (was SSLSoap) Part3 of 3.


Please find enclosed the last part:
SecureSoap-SAMPLES-08312000.zip.
Unfortunately while the code changes for SSL were minimal I
had to change the client interface since there is NO new
URL; for a https:URI. (please try to give one to one of the
older samples! (-:
Sometime later today I will start work on the PKI based
security extensions. I am sorry for not making last week's
IRCchat (and not lobbying for security-) I had an eye
operation that day. Any comments would be very appreciated.
Now an https:URI can be transparently specified for an
http:URI with this version. The proxy information comes from
a Soap.properties file which I am also planning to use on
the server side. The properties file currently has the proxy
password in the clear. In the future this will be encrypted
by the user's private key which I will get from her cacerts
Java file within the appropriate <user.directory> which
could also be the place for her Soap.properties file (A
hierarchical search algorithm for Soap.properties is already
used  in this code base.)
Regards - George


Mime
View raw message