We have an integration scenario that would have been a perfect fit for workflow outbound messages. The only thing that's missing is HTTP basic authentication (so simple!) for the outbound requests. Neither IP restrictions nor the client certificate or a token in the notification are acceptable alternatives for authentication. Is anybody aware of a workaround, a dirty trick or anything that would help to use this beautiful (configurable + scalable + robust = like!) feature of the force.com platform?
Unfortunately outbound messages are very limited in configuration, you get your fields, session id, and the object id and that's pretty much it which means no access to the request headers.
Option 1 - Apex
Apex callouts support header access which will let you do HTTP basic authentication.
Option 2 - Proxy
I haven't used it with outbound messages, but in other scenarios where I had to get around Salesforce header restrictions I setup a proxy that takes the message to or from Salesforce and corrects the headers. In my specific case we wanted to use a basic authentication header to verify requests to Salesforce, but unfortunately Salesforce strips that header. We put a Node.js proxy up on Heroku and it takes input from a webservice with the Authorization header and converts it to X-Authorization.
I wouldn't say its quick and dirty per-se since it requires programming knowledge and periodic maintenance, but it fits your scenario. If you were able to incorporate the target URL into the endpoint for the outbound message it would be able to re-used for different outside webservices.
Another alternative is to simply not trust the payload of the outbound message, and use it instead to trigger your application to read from Salesforce. I.e. just use the org ID and record ID, then make a call on the REST API to read that object. This means you can never be fed bad data.
The downside is that you use an API call (you only get so many a month) for every outbound message.