Mark O'Neill

Originally posted by M.K.A. Monster:
Also nice to think about is the exchangeability of WebServices. When you're using CORBA, it can happen, that CORBA stubs aren't as exchangeble between other that Java en C++ applications as they say they should be.
XML Webservices are so open. It is easy to build options in for example your own programminglanguage to support webservices. The XML format is way too open to compare with CORBA I think.
Regards,
Mark Monster

Agreed - Web Services started out by being seen as "CORBA using XML" and people would often compare it to other RPC technologies which went before: Java RMI, etc. But then people realised that when doing RPC, you often have to pass objects around, and although SOAP included some encoding rules for data, the object-passing and platform-neutral aspects of SOAP were difficult to reconcile. [i.e. it's easy to say "anyone can consume this message because it's XML" - but if it's a serialized Java class in the SOAP payload, good luck consuming that using .NET].
So - the thinking has shifted more to Document-based SOAP [as opposed to SOAP RPC]. This isn't so much "RPC between applications", as "email between applications". This fits nicer with the loosely-coupled and platform-neutral requirements. And it means that ancestors of SOAP maybe aren't CORBA and RMI, but are EDIFACT and ANSI/X12 [i.e. EDI data enveloping standards]. Also, the "Literal" (as opposed to encoded) style for a SOAP body suits document-based SOAP better than SOAP RPC (where objects are frequently passed and must be encoded).
It's interesting to note that .NET does document/literal SOAP by default, while AXIS uses RPC/encoded as default [both can do either, but you have to tweak your code to change the SOAP style]. The story isn't as simple as "SOAP is a new way to do RPC" - it could be "SOAP is a new way to do EDI". [showing my background here - I used to work for an EDI Value-Added Network and I can see the value of XML for EDI].
Hope this helps
-Mark.
Mark O'Neill
CTO, Vordel

Originally posted by Lasse Koskela:

Thanks for the link. However, it didn't do much because I am already aware of the principle of XML digital signatures. What I'm after is a "shrink-wrapped" library for signing a given XML document (a specified part of it) so that I don't have to hand code that logic. And the same for reading the signature, of course.

Hi - I'd recommend the IBM XML Security Suite. Here's some example code written using it - you can see that it's quite high-level and you don't have to deal with the nuts-and-bolts of making the actual signature yourself, although it does help to be aware of the high level structure of XML Signature [ i.e. Reference, KeyInfo, etc]
[ com.ibm.xml.dsig.* and java.security.* namespaces are required ]
KeyStore keystore = KeyStore.getInstance("JKS");
keystore.load(new FileInputStream(keystorepath), storepass);
X509Certificate cert = (X509Certificate)keystore.getCertificate(alias);
Key key = keystore.getKey(alias, keypass); // a private key
if (key == null) {
System.err.println("Could not get a key: "+alias);
System.exit(1);
}
KeyInfo keyInfo = dsig.SignatureUtil.createKeyInfo(cert);
Element signatureElement = signatureGen.getSignatureElement();
keyInfo.insertTo(signatureElement, prefix);
//
// Sign
//
SignatureContext sigContext = new SignatureContext();
sigContext.setIDResolver(idg);
sigContext.sign(signatureElement, key);
doc.appendChild(signatureElement);
dsig.SignatureUtil.printDocument(doc, System.out);
---------
hope this helps
-Mark
Mark O'Neill
CTO, Vordel

Originally posted by Lasse Koskela:

Well, as Web Services are basically about transferring XML messages over HTTP (mostly), there should be few new vulnerabilities when compared to plain HTTP requests.
However, there are some points to consider for the paranoid... The fact that Web Service interfaces are publicized with UDDI makes it easy for a black-hat to figure out where to send requests and how should the request look like, etc. These "dangers" are real only if the designer gets sloppy with security.
What's more of a problem is the propagation of identity and information in a workflow where several enterprises take part in fulfilling a request. On the other hand, those problems are not due to Web Services per se.

Initial Web Services rollouts are tending to be in partner-to-partner situations, rather than to the entire world. The phrase "Web Services" implies to some people "services deployed out to the entire Web", but this is the exception, not the rule, right now, and probably for the forseeable future. Rather, Web Services means "A services oriented architecture implemented using Web technologies such as XML". What it tends to mean in practical terms is "getting XML data from Company X to Company Y, safely and reliably - in a cheaper way than using a private EDI network". This is less of a "big idea" than things like global UDDI directories and ad-hoc business relationships, but it is more practical and actually solves existing problems, rather than making new ones.
So, I agree that the first real problem is managing the identity of access to services. i.e. ensuring that only trusted partners can access the Web Services. This involves processing SAML assertions embedded in SOAP messages sent from partners (indicating that the end-user has been authenticated in their security domain), as well as processing other types of security tokens which are embedded in SOAP messages using WS-Security [e.g. X.509 digital certificates].
In terms of new attacks made possible by Web Services - ones I'm seeing are:
- Providing inappropriate data to a Web Service - e.g. malformed XML, very large messages, broken XML Signature, etc.
- Attacks against security services themselves. e.g. clogging attacks against processors of XML Encryption or XML Signature structures. For example: validating XML Signature data may include pulling down a resource based on a URI in the "resource" section of the XML Signature structure. If this resource is a 100MB file, the signature checker will grind to a halt. 100 concurrent similar messages and the whole system grinds to a halt.

- Replay attacks [i.e. intercepting and sending the same SOAP message again. It's important to realise that if your system will authorize a certain SOAP message, will it authorize the exact same message if it's received again - if so, it's potentially vulnerable to a replay attack]
In protecting against these attacks - there is an architectural choice to make. Do you secure the traffic flow [i.e. put an XML Gateway/Firewall in place as a proxy], or do you secure the endpoints themselves [i.e. build security into your code, or use an XML security tool which has agents that hook into your XML platform].
-Mark
Mark O'Neill
CTO, Vordel

Originally posted by Rama Raghavan:
Welcome Mark..
What kinda of additives/bells and whistles has Microsoft added to web services that is over and beyond the call of the standards/protocol?
With a known history (unfortunately), always wonder what holes Microsoft leaves open on this front..
Rama

Hi Rama,
Looking at the Microsoft/IBM WS-Security model, I can see that a lot of the architecture fits well with Kerberos. Kerberos, of course, is built into Windows 2000, Windows XP, and Windows Server by implementing a Kerberos SSP (Security Support Provider). Kerberos fits the WS-Security model somewhat better than SAML does, for example.
That said, WS-Trust defines how to apply for a different token format (i.e. "token translation") - e.g. how to request an SAML assertion to send to a system which doesn't process Kerberos tickets. So, users are not locked in. I suspect that Web Services security is an area where lock-in is almost out of the question.

Originally posted by Stanley Tan:
Mark,
I'm using SOAP headers right now for authentication. I have a .NET Web service that exposes Web methods but requires a SOAP header to be passed along with the invocation. I've created a Java stub to the .NET Web service using AXIS and all is working fine until I call a method that requires a SOAP header. How do I go about specifying a SOAP header from a Java client that uses a stub generated from AXIS? Thanks for any input!

Stanley

Hi Stanley
Putting security data into SOAP headers now means using WS-Security. In terms of AXIS-friendly toolkits for WS-Security, the IBM WSTK is the most useful [e.g. by comparison, VeriSign's TSIK implements WS-Security but has its own SOAP stack].
WS-Security defines how security information is included in a SOAP header. At a simple level, it defines a "Security" element, and the format of security tokens which are put into that element (e.g. a UsernameToken for userid/password, or a BinarySecurityToken for an X.509 digital certificate). It also defines how to apply XML Signature and XML Encryption to these security headers, and to the rest of a SOAP message also.
You haven't specified which security parameters should go into the SOAP header, but let's say if you want to use the Java WSTK to include an X.509 certificate, then (ironically) the best place to learn how to do this is at this MSDN article:
http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsejavainterop.asp
As usual with Axis, you have to configure a deployment descriptor (WSDD file). The WSDK uses information in this file to determine the signing key, which is taken from a Java keystore (JKS). Note that the private key password and the JKS password both sit in the clear - this clearly isn't ideal and care should be taken that access to this WSDD file is guarded.