1 Raindrop

Web services security training in NYC

If your company is doing SOAP, Web services, SOA, Rest or XML, and you are looking for ideas on how build security into the system, come to NYC in March. I am teaching Web services security in NYC on March 10, 11, all the details are here. This is a public version of the training session that I do for companies and conferences, and you can read reviews here.

You Got Chocolate in My Peanut Butter! Rilke weighs in on Rest and SOAP

Rest and SOAP are supposed to be about interoperability, it is fascinating that they are at each other's throats. I don't see the same level of malice from Rest or SOAP towards say J2EE or Corba. Wonder why this is? Either way it is ironic that proponents of interoperability technologies would want to vanquish each other. Rilke [1] says we need to let go of irony, and not be governed by it. So too must we let go of SOAP v REST. They actually can play nicely *together*, Mark O’Neill gave a good “real world” Web services security talk last week at OWASP (at eBay where I believe these two *do* play nicely together in actual fact), in the case studies section he describes some security considerations for SOAP-Rest integration

The simple fact is that you may need/want to rely on Rest on the edge, but you may also want to leverage SOAP's security mechanisms as you get closer to your enterprise foo (ERP, CRM, etc.). From a security perspective it is hard to do much useful without authentication and integrity, so an STS plays an important role. The example below shows one way, this is similar to the approach that Ping Identity uses in their Ping Federate Web Services.

You got Rest in my SOAP, oh wait, it can work together...and thither irony never descends.

[1] Rainer Maria Rilke:
Irony: Do not let yourself be governed by it, especially not in uncreative moments. In creative moments try to make use of it as one more means of grasping life. Cleanly used, it too is clean, and one need not be ashamed of it; and if you feel you are getting too familiar with it, if you fear this growing intimacy with it, then turn to great and serious objects, before which it becomes small and helpless. Seek the depth of things: thither irony never descends—and when you come thus close to the edge of greatness, test out at the same time whether this ironic attitude springs from a necessity of your nature. For under the influence of serious things either it will fall from you (if it is something fortuitous), or else it will (if it really innately belongs to you) strengthen into a stern instrument and take its place in the series of tools with which you will have to shape your art.

Letters to a Young Poet
(translated by M. D. Herter)

Two States

James Clark, Technical Lead of the original XML Working Group, neatly summarizes why defense in depth is mandatory not optional in Web services, be they Rest, SOAP, whatever:

XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign.

The lack of tooling for secure coding is a real problem, the WS-Security people are ahead here for sure, but there is a lot that needs to be done in all camps. Bottom line: We need a defense in depth security model that composes elements of both the security of the processing state (service security if you will) and the data itself (for example message level security), or as some great American Poets called Pavement put it:

two states
we want two states
north and south
two, two states
forty million daggers ...
two states
we want two states
there's no culture
there's no spies
forty million daggers ...

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

Rise and Fall of CORBA

This article has some good content on what emerging technologies like SOAP may learn from past successes and failures, but it appears to be more commercially motivated than anything else. The usual suspects (complexity, bloated specs, lack of features, and Microsoft) are rounded up as conspiring to constrain CORBA's growth. Of course, the reality is that CORBA serves lots of mission critical functions today.

The lack of features section contains this:

CORBA provides quite rich functionality, but fails to provide(....):

Security. CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.

Now I am not a "let the network firewall solve all your app security problems" guy, but I am sure it will come as quite a surprise to pundits like Schneier ("SOAP is designed as firewall friendly protocol, this is like a skull friendly bullet"), et. al. that SOAP's ability to traverse firewalls is actually a boon for security. Schneier circa 2000:

That's right. Those pesky firewalls prevent applications from sending commands to each other, so SOAP lets vendors hide those commands as HTTP so the firewall won't notice.

Let's continue the DCOM example. So what if DCOM runs over a firewall?

DCOM is Microsoft's main protocol for inter-application communication. It's not just used by programs that are intended to be servers; it's used for all sorts of desktop communication and remote access. The result is that an average machine has dozens of programs using DCOM. Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to "logagent" and including the catchily named "{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours by bringing up a Command Prompt and typing "dcomcnfg".

Now, there are lots and lots of ways to secure DCOM applications, so maybe all of those applications are happily responding only to authenticated requests from the local machine. On the other hand, there are lots and lots of ways to make DCOM applications insecure, so maybe one of them is just waiting for somebody to send it an entirely unauthenticated request to overwrite selected files on my hard disk.

Firewalls have good reasons for blocking protocols like DCOM coming from untrusted sources. Protocols that sneak them through are not what's wanted.

SOAP was also not generally seen, at the time the ACM article refers to, as an improvement over DCOM and CORBA security, quite the opposite. So anyway, SOAP is not the death of distributed security either or even the death of firewalls, and I think WS-*, SAML, et. al. contain some valuable improvements for security but these nothing to do with firewalls, and I have not seen security as a reason for organizations moving to SOAP Web Services and away from CORBA. And in either case, the tricky bits like IAM and input validation remain.

Secure Your SOA: Web Services and XML Security at OWASP Europe

4/30 is the last chance for early registration for OWASP Europe. I will be teaching a one day class on Web Services and XML security -- the class focuses on the risks inherent in this programming model, what the standards are, how to use them, and where you still need to use custom code and configs to deal with the security issues. This is a variation of the classes that I provide for customers onsite

REST v SOAP debate impact on security services architecture

Mark O'Neill's RSA Presentation on Security for REST Web Services makes an important point for security architects who are dealing with developing security services for budding SOA initiatives - how will your security services (which rely on WS-* functions and SOAP) be able to deal in a RESTful web services paradigm? This is not a trivial question because while enterprise architects may design and purchase solutions that rely and mandate the former, developers can easily circumvent with a HTTP Get. Part of this gets back to a framework versus roll your own debate that I blogged awhile back.

Security architects cannot afford to take enterprise architect's whiteboard and Visios mandating a WS-* (or any technology) world at face value instead they must engage developers, BAs and other stakeholders to deal with the reality of runtime as opposed to policy and design time. XML in and XML out may be the design, but the runtime reality could well be HTTP Get in and XML Out under REST rendering the shiny new XML security based solution blind to large amounts of traffic.

Maximum flexibility to deal with different tactical deployment realities is an important property in security tools, not just compliance with Visio drawings. The ability to enable security protocols in integration scenarios composed of hetergeneous technologies and usage paradigms yields the widest risk management coverage. In this case it pays for security architects to be the fox not the hedgehog.

This is also why I think STS technology will be very successful, because the security protcols that STS and WS-Trust integrate: SAML, X.509, Kerberos, are generally putting arbitrary boundaries around technical domains while the business reality is the opposite - more integration not less. Protocols which continue to enforce isolation ultimately fail when their subjective, isolated concepts meets up with the integration objectives reality rendering the system as a whole less secure.