1 Raindrop

More on Fallacy #4

Steve Jones on Rest and Distributed Computing Fallacies

One of the objections I've had about REST for a while is that it appears to ignore Deutsch's fallacies of network computing

1. The network is reliable.

2. Latency is zero.

3. Bandwidth is infinite.

4. The network is secure.

5. Topology doesn't change.

6. There is one administrator.

7. Transport cost is zero.

8. The network is homogeneous.

Now REST specifies 8, assumes 1, 2 and 3 and takes 4 to mean HTTP/S with Basic Authentication. Now to be clear I've seen people doing Web Services who believe in pretty much all 8 of these fallacies and they create crap systems. But with things like WS-RM and WS-Security at least there are answers to a few elements.

That basic auth is bypassable has been known for some time, thanks to Amit Klein. It would be nice to Restafarians move the conversation towards better security models like SAML and WS-Security. The current state for Rest is both disappointing and weak. The response side is pretty solveable using XML Signature and XML Encryption to sign and encrypt the responses (of course someone will need to tell the "you just leverage the existing infrastructure types" that we'll need to be deploying keys and certs to all the endpoints but at least the primitives are there on the response side), the request side remains problematic.

More on the Fallacies by Arnon Rotem-Gal-Oz, who incidentally if you are interested in building a secure service has an interesting Service Firewall pattern, which I refer to as a TIDE firewall - dealing with Tampering, Information Disclosure, Denial of Service, and Elevation of Privilege threats at the edge. I understand why Arnon left Spoofing off his list, but would like to see him add audit logging to deal with Dispute.

CXF, Axis2 and ESB Security

Just saw here that CXF has graduated to an Apache top level project. I have long been a fan of CXF and Celtix before that. In my SOA, Web services security class we generally use both (and Axis2) to demonstrate concepts and build security into web services.

In terms of comparing security features in CXF and Axis2, it looks like CXF is relying on WSS4J for security services just like Axis2. WSS4J gives a nice way to program to XML Signature and XML Encryption (which is provided by xmlsec), but it looks to be implemented differently in CXF where you are coding properties for WSS4J interceptors

outProps.put(WSHandlerConstants.ACTION, "Signature"); outProps.put(WSHandlerConstants.USER, "myAlias"); outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS, ClientCallbackHandler.class.getName()); outProps.put(WSHandlerConstants.SIG_PROP_FILE, "client_sign.properties");

Whereas, Axis2 has an additional layer on top WSS4J called Rampart, Rampart has the notion of Outflow and Inflow security where Rampart handlers perform operations like Sign/Verify, Encrypt/Decrypt and so on. These are configured in XML as opposed to being coded:

<parameter name="InflowSecurity"> <action> <items>Timestamp Signature Encrypt</items>

The other thing that Rampart is the ability to hook into WS-SecurityPolicy as the great security architect Bill Gates says: "security should depend on policy not topology.", and WS-Trust so now you can build out an Security Token Server (STS) in Rampart. How you can sell/buy/run an ESB with out a STS is a continuing mystery to me - yes ESB vendors that is directed at you.

Anyhow, it looks to me that the Apache community has now produced not one but two ESBs that have potentially far more advanced security functionality than what is generally available in the ESB product categories.

By way of contrast - until the day I die, I will never understand this statement from our friends at IBM regarding ESB security:

“From the product design point of view, WebSphere Message Broker as an ESB is not the right place to implement WS-Security functionality. However, WebSphere Message Broker definitely is able to deliver the SOAP message with security credentials to its destination”

Great. We can deliver the message. We don't know who sent it, we cannot tell you if its been tampered with, but we won't lose it. What's interesting of course is that IBM sells another ESB Datapower that like its XML Security Gateway compadres is perfectly capable of

1. Delivering the message
2. Performing basic security services like authN, authZ, and so on

You can certainly complement WMB with Datapower or other XML Secrity Gateway and I know that is something that IBM pitches in its designs, but there is a big difference between realizing you have to complement and saying its not the right place at all. The graphic below shows possible options of implementing security in an ESB.

Of course there is a fourth approach which is you have security on the ESB and a XSG adapter, and this is often the best approach. I will have more to say on ESB security shortly, but in the meantime, should we really be worried about delivering things that we cannot verify? It seems to me that this approach leads to a highly reliable Sgt Schultz-style "I know nothing, I see nothing" implementation.

In the meantime, big ups to the Apache community for putting some hooks into interesting security primitives that facilitate building out much more advanced security architectures.

A claim by any other name is still a claim even if its Restful

I am really enjoying this wonderful new world of Claims-based access control (CBAC), and I think the way that the encryption and signatures have been packaged up into claims (if you like your coffee with WS-*) or assertions (if you like a dab of SAML) is allowing us to deploy security architectures that solve a lot of age old problems. I call 'em claims even though MS/IBM hijacked the term from the SAML people it is shorter.

Rest application need claims too. As Don Box says the rest authentication story blows chunks. Now, you see people reinventing WS-Security in Rest (because they realize they need stronger claims) and unfortunately choosing the weakest token the Username token, which in turn encourages bad programming practice. Piers Cawley on the Rest authentication tarpit:

The problem with implementing the Atom Publishing Protocol is that one of the client apps that we want to support, Nokia’s LifeBlog mobile app, only supports the adaptation of the WSSE UserToken authentication protocol recommended by Marc Pilgrim. There’s lots to like about this protocol, especially the way it allows CGI based servers to take control of authentication without needing access to Apache’s .htaccess or requiring mod_digest to be installed. However, the design of the protocol is such that there’s no way to avoid storing the user’s password in plain text on the server. Which we really, really, really don’t want to have to do.

This would not be a big deal if it was just a one off, but your authentication story is the key to your access control and while authentication can never be perfect, there is a lot of evidence that good ol' username and password isn't that good any more. The problem is not with WS-Security, the problem is the token. While Rest people are reinventing WS-Security they should feel free to not use the username token and instead graduate to Kerberos, X.509, and SAML tokens.

A claim by any other name is still a claim, but some claims are stronger than others.

My larger problem with how I see Rest applications doing authentication is that they still after all these years rely on the old school approach where the server authenticates everything. Umm...are we on a mainframe or something? Why not separate the identity provider from the service provider like the rest of the world? Why send your authN creds across the wire every time? I have not tried but I assume an adapter to some of the SAML profiles would yield this separation quite nicely and give back an address to talk to, and the authN/authZ negotiation could be handled by the IdP and SP allowing the Rest client to talk directly to HTTP verbs served by the server...

RSA Talk

I am speaking with Brian Chess on "Breaking Web Services". Should be fun.

Security in SOA - It's the Car, Not the Garage

I have an article on SOA Security in the latest issue of Thomas Erl's SOA Magazine. The article is called Security in SOA - It's the Car, Not the Garage, abstract:

Interoperable software architecture requires interoperable security mechanisms. Security is frequently looked at as a black art, but in reality the core concepts of security - knowing your assets and designing for failure - are just good engineering practices. This article focuses on applying those practices to service-oriented solution design with an emphasis on considerations raised by authentication, authorization, auditing, and assurance.

The introduction:

When I park my car in the garage, I lock it. Why? Well, although I would hate for someone to steal my snow shovel and hockey sticks, my car is much more valuable to me. Security is about managing risk, specifically protecting valuable assets like my car. I have a higher level of protection on my car than on my garage. In dollar terms, the contents of my garage are orders of magnitude less valuable than my car. I could spend a lot of money fortifying my garage, and that would add some security to my car while it is parked there, but it is not a cost-effective investment. First, my car is the asset of value, and second the garage - no matter how well protected it is - doesn't move.

Car manufacturers know this, insurance companies know this, consumers know this. Even media publishers know, yet in the common enterprise, programmers and architects seem to roam in ignorance. Your average download of a Michael Bolton song carries a far higher level of security than valuable user data, like passwords, social security numbers, and credit card details. Why do we keep protecting critical data with point-to-point security solutions (like SSL) that protect the transmission channel, but leave the valuable assets being transported wide open everywhere else? This is a critical question that needs to be answered in order to successfully add an effective layer of security to an SOA.

The article looks at security architecture considerations for authentication, authorization, auditing and assurance in SOA.

**

Web Services Security training, NYC, March 10-11

Web services security training - tool survey

I am doing a public training class on Web Services security in NYC, March 10-11. All the details are here. There are still some slots available. Several people wrote to ask about what tools we use. This is a quick list of some of technologies, I have used in past classes, we may have some additional demos and tools by March, but this list is a pretty good start ;-P

Web Services frameworks
Apache CXF - very interesting open source Web services framework with support for JMS, SOAP, and Rest
Apache Axis & Axis2
.Net
Metro - interesting framework from Sun for interop with WCF

Identity
PingFederate - leading federation tool, we'll look at browser based SSO with SAML
PingFederate Web Services - we'll look at how to implement a STS in Web services
Bandit - Cardspace, authorization, and auditing

Security Services
VordelSecure - XML gateway, comprehensive web services security policy creation and enforcement, deploying decentralized security services
Apache Ramparts
modecurity

Testing
Soapbox - web services security testing
WebScarab - web services fuzzing

Static Analysis
Fortify SCA - how to scan your web services code for security bugs *before* you deploy

This is just a quick list, I may add some new tools before March. If you are using tools of these types in your company you may find it interesting to attend.

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)

Speaking at OWASP Twin Cities

I am speaking at the OWASP Twin Cities meeting next week, since it is an OWASP meeting I am doing a top ten list (not an official one) - Top Ten Web Services security issues. Will focus on practical issues in securing web services with actionable countermeasures you can build into your web services.

Also, it looks like Sam Buchanan will be speaking on the New and Improved OWASP Top Ten.

OWASP Helsinki

In Helsinki, giving the second day of my Web services security training session. I am also speaking tonight at OWASP Helsinki on Web services security. Since it is an OWASP Meeting, the presentation is a top ten list for Web services security issues (please note - NOT an official OWASP Top Ten list).

Issue 1. You're not spending enough on app security
Issue 2. Know your standards
Issue 3. Use message level security
Issue 4. Use longer keys
Issue 5. Validate input
Issue 6. Avoid naive sign and encrypt
Issue 7. Scan your stuff before someone else does
Issue 8. Look out for XDoS
Issue 9. Implement a XSG
Issue 10. Reliability is cool (WS-RM)