Messages All The Way Down · HTTP is a decent and under-appreciated protocol, but in the end maybe the most important thing is that it forces you to think about the messages and how you exchange them. There’s no pretense that Remote Procedures are being called, or Object Models are being shared; I send you some bits and some metadata about them, and you respond with the same. It turns out that in the HTTP universe, at that point our conversation is over, and that turns out to be a good basis for building applications, but the key thing is putting the messages, rather than what they allegedly stand for, at the center
That's great - the message is the center - now REST just needs message level security model and mechanisms like WS-Security. SSL is what is usually bandied about as a security model by Restafarians, but we know from Deutsch, Gosling, and Joy that "the network is secure" is the fourth fallacy of distributed computing.
Can't WS-Security be reused outside of the WS-* ecosystem?
Posted by: asbjornu | May 03, 2007 at 05:38 AM
That is the ninth fallacy: end-to-end security will save the day. Why?
- large number of messages can be verified and decrypte only by servers, with private keys stored on servers, without human interaction. It is not feasible to enter a PIN for each message
- storage of received messages can only be based on shared secrets, because private keys are bound to a person, and organizations have to rely on roles, never a single person. Consequntly the private keys hove to be owned by servers, therefore being degraded to (locally) shared secrets.
- anyway, high availibily operation demands keystores that are not protected by passwords for fast recovery, again weakening private keys to kind of shared secrets.
Hence, from an operational perspective the conceptual differences between SSL point to point security and XML-DSig based end-to-end security is blurred. May be that one can extend the trust relationship one or to network hops further past the first application gateway to some "inside" secure zone, but the basic problem remains the same: One has to trust some shared infrastructure, that has the keys for and the power over cryptografic operations.
Reliance on SSL is in most security scenarios no disadvantage, so RESTful life may prosper:-)
Posted by: Rainer Hoerbe | May 06, 2007 at 01:07 PM
quark - you can use the primitives of ws-security (xml encryption and xml signature) outside of ws-*
rainer -
"- large number of messages can be verified and decrypte only by servers, with private keys stored on servers, without human interaction. It is not feasible to enter a PIN for each message "
you don't need to enter a PIN for each message
"- storage of received messages can only be based on shared secrets, because private keys are bound to a person, and organizations have to rely on roles, never a single person. Consequntly the private keys hove to be owned by servers, therefore being degraded to (locally) shared secrets."
why are private keys bound to a person?
"- anyway, high availibily operation demands keystores that are not protected by passwords for fast recovery, again weakening private keys to kind of shared secrets."
keystores not protected by passwords?
"One has to trust some shared infrastructure, that has the keys for and the power over cryptografic operations."
really? why? i can aggregate and put all my customers' data at risk, because it saves the developer 5 mintues?
"Reliance on SSL is in most security scenarios no disadvantage, so RESTful life may prosper:-)"
REST will prosper in high value transactions once it has addressed the above. until then you have impedance mismatch with a message oriented programming model (REST) and a transport oritented security model (SSL).
Posted by: Gunnar | May 07, 2007 at 04:38 PM