In the past I noted that while REST doesn’t say anything about transport- or message-level security, there does not currently exist any standard means of using message-level security in a RESTful system. I was wrong.
I don’t know how I missed it, but section 5 of the Atom Syndication Format (Atom) describes how to encrypt and sign an Atom document. Like WS-Security, Atom leverages the existing W3C specifications for digital signatures and encryption. What does Atom have to do with REST? Technically, nothing. It’s just a well known, high-level, media type that you are strongly encouraged to use as your representation formatâ€”as an envelope around your content.
Traditionally, Atom feeds are polled by subscribers and thus forms a pub/sub model. Securing the feeds or the internal entries will allow me, for instance, to subscribe to my cell phone usage data and know that the message is confidential, unmodified in transit, and really created by my cellular provider. But what about the more common request/response needs, where, say, a buyer wants to purchase 1,000 widgets? Well, that’s where the Atom Publishing Protocol comes in. I, the supplier, can expose my order processor as a resource (http://example.com/orders) and my customers can POST a signed and encrypted purchase order wrapped up in an Atom entry to that URL.
What about authentication credentials? Well, if the entry is signed, then the signature serves as the originator’s credentials. Coolness! If for some reason digital signatures don’t work for you, then Atom supplies an extensible author element. It’s lacking a password field, but to address that just drag in the WSS Username Token Profile: