Question of Risk

Eric Newcomer, as is his wont, gets right to the heart of the issue in WS-* vs. REST is not the question.

The big question isn't whether WS-* is too complex, or REST is better. The question is "for what?" In the context of this workshop, the "what" is enterprise software standardization.

My context in looking at these technologies is security. Security is generally practiced as a subset of overall risk management. The risks are comprised of threats and vulnerabilities against some set of assets. In security architecture, countermeasures are selectively deployed to deal with the threats and vulnerabilites. This is very subjective terrain. The problem I have with the way REST security is generally described is that SSL and firewalls were good enough in 1995 so they are good enough now (certainly not all RESTians say this, but a very high percentage do), and the problem I have is when a REST programmer makes these tradeoffs and decides "heck, I don't need message level security", they are making that tradeoff on someone else's behalf, specifically their identity credentials. At what point does developer productivity intersect with responsibility and due care of users identity credentials?

Here is an example of Tim Bray comparing PHP, Rails, and Java frameworks for web application building. The comparison criteria are Scaling, Dev Speed, Dev Tools, and Maintainability. We are talking web apps and security is not even a first class member yet two classes of developers' concerns are. I am not picking on Tim Bray, this is just a good example of how many development organizations prioritize - what is easiest/best for me, not what is protects my user's assets/identity/data the best. I absolutely think dev tools and speed are important and should be first class members in an evaluation, I am just arguing for security to be there too especially for web apps.And there are real differentiators in security between these two. But it all starts with developers looking not just inward but also outward and protecting their users. The young identity himself, Andre Durand, noted:

• When GM was recently asked, "...are you worried about losing the #1 spot as the worlds largest car manufacturer?" the answer was, "...we're very concerned about maintaining our #1 position as the largest manufacturer of cars."
• When the same question was asked of Toyota, "...are you focused on becoming the #1 car manufacturer in the world," the response was, "we're concerned quality is slipping."

Part of the quality that developers need to consider is not whether or not cars are easier or harder to build if they do or don't have airbags; but rather under what conditions do you want your car to have air bags, ABS, and so on, and then what frameworks has the best airbags and ABS support.

Comments

[Dave Tauzell]

About Message Level Security:

It isn't just developers, but whole industries as well.

Take for example the NCPDP NEWRX transaction (the xml version to play well with REST and SOAP), which is designed to electronically submit prescriptions.

The transaction itself does not define any message level security. So let's say that you want to send the transaction using SOAP.

Most of these transactions are sent through a third party service. Message level security will prevent the third party from viewing the data. Thus, they cannot translate to/from other versions or to/from other similar transactions unless they can access the message. So either you give the third party services the ability to view the data or you make all end parties follow the same standards.

I'd say that in this case REST vs WS-* has little bearing on the end-solution. Nor does developer preference. What has the most bearing is the total cost from an industry standpoint.

[Gunnar]

"Most of these transactions are sent through a third party service."

Ahhh...but WS-Security and SAML can both support multiple namespaces and authorities for validating tokens. So you can have an interemediary token for routing messages around a network where you may care moe about integrity for example, and another token in the same message to protect sensitive data where you may care more about confidentiality.