Skip to content

Message Level Security and REST

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 ( 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:

<?xml version=”1.0″ ?>
<entry xmlns=””
<title>Purchase Order No. 1234</title>
<id>Some Unique Identifier</id>
<name>Peter Lacey</name>
<content type=”application/xml”>Inline Purchase Order</summary>
(Sorry about the lack of formatting in the XML fragment. I can’t get WordPress to behave.)

{ 21 } Comments

  1. Bob McCormick | May 25, 2007 at 2:27 pm | Permalink

    I like the direction you’re going in. Atom is definitely much simpler than the whole SOAP/WS-* stack, and I haven’t seen any Web Services uses that I can recall that be couldn’t be modified to fit in a CRUD framework.

    I also think it’s quite cool that you’re re-using the WSS Username Token Profile. Take what works, dump what doesn’t! Very pragmatic.

    However, I think there’s still more work to be done on Atom security, message level or transport level.

    For example, section 15.2 of the APP spec specifically says that APP *is* vulnerable to replay attacks and there there is no standard provision within the protocol for detecting replay attacks.

    This is a *major* potential security problem. A duplicate post to a weblog is no big deal. A duplicate post to a bank account *is* a big deal!

  2. Pete | May 25, 2007 at 3:17 pm | Permalink

    Bob: I’m not a security expert, but replay attacks are notoriously hard to defend against. But despite the fact that APP punts on replay attacks, it can be addressed in Atom.

    When signing a message make sure that some time sensitive information, sequence number, or unique identifier is part of the signed content. Since Atom entries have a mandatory ID field, include the ID in the signature (better yet, include the whole entry), and make sure the server throws away any message containing an ID it’s seen before.

    If the woman in the middle (I think her name is Eve) tampers with the ID, it invalidates the signature and if she resends the message unmolested, it gets rejected (and logged) as a duplicate by the server.

    You can further optimize things by rejecting all messages older than, say, five minutes. That means you only have to cache the IDs of messages posted in the last five minutes for looking up dups. Fortunately, Atom entries mandate an “updated” element, which must also be included in the signature.

    Oh, and transport-level security, i.e. SSL, is not vulnerable to man-in-the-middle attacks, as it barrels right through them.

  3. Bob McCormick | May 25, 2007 at 5:44 pm | Permalink

    You don’t really have to be a security expert to program defensively. Just keep thinking “how could I break this?”. It’s a lot like developing unit tests. :-)

    I can’t seem to find the ID field in the APP spec, but I’m probably just overlooking it. You’re correct that including signed hash of the ID could ensure the message is unique, but then you’ve got to consider how long does the server need to keep ID’s it’s seen? A signed hash of the combination of the ID, a timestamp , and some kind of validity duration is probably needed.

    But the problem is finding a *standard* way of doing it. If everyone is doing their own thing, using different elements, different data formats, etc. it starts to be the same kind of ambiguous non-interoperable mess that WS-* is. :-)

  4. Pete | May 25, 2007 at 6:17 pm | Permalink

    Bob:The APP spec does not stand alone. It works with the Atom Syndication Format (linked to above). It’s there that you will find the and elements.

    How long the server keeps previous IDs around is up to it - five minutes for a moderately busy server seems like a good place to start. Adjust the window as needed.

    Note, that what I’ve described is standard - it’s Atom. There’s a place, granted, for best practices. I think I’ll put that in its own post.

  5. Mike Champion | May 26, 2007 at 3:41 am | Permalink

    This seems to me like the first step down a road that leads to reinventing large chunks of the WS-* stack. What you say is true AFAIK, but leaves numerous details unspecified, which eventually need to be nailed down in bilateral contracts or higher-level specs. That’s how WS-* got the way it is … For example, WS-SecureConversation was invented to address some of the attacks that WS-Security allows, WS-Trust was invented to address the real-world challenges of exchanging security tokens, and then there are the WS-Policy and WS-SecurityPolicy specs for constraining the policies associated with these things …

    Then there’s the little detail that nobody will really trust any of this until it has been tested by fire when there is real money at stake and real thieves tying to steal it. I’m happy to see that APP provides an extensible framework that can “drag in” bits and pieces of other specs to provide a simple but adequate security model for blog-type data. Obviously WS-* would be overkill for that scenario. On the other hand, do you want *your* bank leaning over the bleeding edge and applying APP to a much more challenging security secenario just because the alternatives are ugly and complicated?

    There is a lot of truth in the assertion that WS-* is an “ambiguous and non-interoperable mess”. The question is whether the way forward is to disambiguate through rigorous interop testing, or to start over with something like REST, Atom, and APP. I’m highly skeptical that the result would be much different — these are intrinsically hard problems, and finding a decent tradeoff between preserving the infrastructure that works today and providing a modern interoperable veneer over it just not easy. Doing it via negotiations among fierce competitors doesn’t make it any easier, to say the least. Even if, for the sake of argument, REST/APP was a technically superior approach than WS-* is, it is wildly overoptimistic to assume that the other challenges that have inhibited WS-* interop will not show up in the approach you propose.

    In short, the ugly complexities of WS-* reflect hard-won knowledge much more than they are due to incompetent design or pathological politics. Even in some dream world where you have altruistic geniuses without egos designing new RESTful protocols from scratch, the intrinsic complexities of the security domain will intrude, and I’m very skeptical that the result would be notably better.

  6. Anne Thomas Manes | May 27, 2007 at 5:21 pm | Permalink

    Why do you think that an Atom envelope is all that much better than a SOAP envelope? In our off-blog discussions, you indicated that the best approach is to use the HTTP application protocol as the message envelope. If you use an XML envelope, then you must sacrifice the power of the pervasive HTTP infrastructure to manage the communication process.

    The bad news is that we don’t have standards that allow us to support end-to-end security using an HTTP envelope. If you need to pass authentication credentials or you need to sign or encrypt specific content within the message, then you need to use an XML envelope.

    So why do you view the Atom envelope as inherently better or more RESTful than a SOAP envelope? If you want to use a pub/sub model, then Atom makes sense. But if you want to use a request/response model, then SOAP makes more sense.

  7. Pete | May 27, 2007 at 8:45 pm | Permalink

    Anne: Follow the link to Bill de hOra’s blog for your answer; copied here for convenience: In summary, the Atom envelope is a better envelope than SOAP’s because it has a mandatory unique identifier and a mandatory timestamp. Furthermore, an Atom entry’s content is not restricted to XML, but can be any media type–including binary.

    I, nor no one else, has ever had a problem with envelopes. Nor is an envelope antithetical to HTTP–even HTML has an envelope. What I said, was that HTTP is not without an envelope–the HTTP headers fulfilling that role. Using another envelope does not sacrifice the power of HTTP, so long as the HTTP headers and standard media types (self-descriptive messages) and the other constraints are are still respected. Which is exactly what Atom and APP does, respect HTTP and allow your infrastructure to keep working. In other words, using an envelope pattern with HTTP works just fine, even when passing credentials or signed and encrypted messages from end to end.

    Update: Anne, while the above is correct, after more thought on the subject, I see your point on authentication information in the envelope.  There’s much more thinking needed on this subject, and I’ll write more about it soon.  For now, I’d say this much: Basic+TLS is likely sufficient for 80% of use cases.  For the rest something new will be needed.  Currently, there are any number of alternatives: Amazon and Google, for instance, have custom  (though published) auth schemes.  Then there’s things like WSSE.  However, if the credentials are published in a custom header or in the message body, then at the very least the Authorization header should be set to something so that caches do the right thing.  More later.

  8. John Bull | May 30, 2007 at 10:21 pm | Permalink

    There’s much more to securing a message than just referencing XML-Signature and XML-Encryption. As someone commented on this post, there’s prevention of replay attacks. There’s the requirement to include and reference arbitrary keys/certificates/username-passwords. There’s the requirement to indicate whether you signed the message and then encrypted it or vice versa. There’s the requirement for multi-factor authentication in case you are talking to a bank web service.

    All these mechanisms are currently supported by WS-Security (which also uses XML-Signature and XML-Encryption). It would make sense to define a simpler profile of WS-Security for securing HTTP messages rather than to reinvent a new format.

    What do you think?

  9. Pete | May 31, 2007 at 8:35 am | Permalink

    John: What do you think?

    I agree 100%. In fact, there’s even more to security than you enumerate. It’s a hard problem. This post was really just to point out the fact that Atom allows encryption and signing.

    The long and the short of it is that RESTful HTTP has some significant limitations when it comes to security, and we need to start thinking about them now. Sometime soon I’m going to return to this subject and spell out the current issues and possible means of addressing them. Right now, though, my plate’s kinda full.

  10. Bob McCormick | June 1, 2007 at 10:04 am | Permalink

    This is probably starting to go a bit off topic, but I’m beginning to wonder of message based security, or message based semantics in general, are appropriate for REST.

    The more I think about it, the more I think REST isn’t message or document based, it’s a form of RPC. REST is RPC that’s restricted to an agreed upon interface of 4 procedures (POST, GET, PUT and DELETE).

    Your thoughts?

  11. Andria Mathony | May 10, 2012 at 3:09 am | Permalink

    The information you have was perfect that we’re seeking and i also really enjoyed the content I would like to visit your site again from now on

  12. beepollenweightloss | May 2, 2013 at 10:58 pm | Permalink

    I’ve yet to test the item but wish to review the company 361slim. I had been pretty pleasantly surprised at the excellent communication from the representative as well as the amazing comply with up to verify i’d obtained my order. She definitely went out of her way, and totally unprompted. I am so happy together with the support and will certainly be back!

  13. hermesreplicabirkin | June 21, 2013 at 4:39 pm | Permalink

    Can you please send by e-mail me the code for this script Pete Lacey’s Weblog : Message Level Security and REST or please let know me in detail concerning this script? hermes replica birkin

  14. manish jivtode | July 10, 2013 at 11:24 pm | Permalink

    i have study limitations of message level security in rest pl send me limitations of msg level sec.

  15. online Marketing | September 16, 2013 at 12:55 am | Permalink

    Ahaa, its fastidious dialogue regarding this piece of writing
    here at this website, I have read all that, so at this time me also commenting
    at this place.

  16. freight factoring+ | September 21, 2013 at 3:57 am | Permalink

    I am curious to find out what blog platform you have been working with?
    I’m experiencing some small security problems with my latest website and I’d like to find something more
    safeguarded. Do you have any solutions?

  17. Aimee | October 27, 2013 at 8:06 am | Permalink

    It’s not my first time to pay a quick visit this website, i am browsing this site dailly and
    get fastidious information from here daily.

  18. Replica burberry bags- Free Shipping! | November 7, 2013 at 10:25 am | Permalink

    my book has a dark blue cover

  19. Top Eleven Be a | December 6, 2013 at 6:29 am | Permalink

    Several of these games are worth some time and are actually quite fun.
    The popular epub format is written in XHTML, which is nothing but an advanced
    version of HTML. The player had his picture, albeit with a strange grimace and
    geeky affects.

  20. Juliet | December 11, 2013 at 12:26 am | Permalink

    All patients received triple immunosuppression with tacrolimus, mycophenolic acid,
    and prednisone, conducted by Buffalo General
    Hospital, Buffalo, posted in Pub - Med, researchers found that Seven patients (2%) developed wound infections.
    A technician administers the exam using a specifically designed x-ray machine.
    How could it be that the pelvic pain returned with everything removed.

  21. music online mixer | March 6, 2014 at 2:55 pm | Permalink

    Every weekend i used to visit this website, because i wish for enjoyment, for
    the reason that this this website conations actually good funny stuff too.

{ 6 } Trackbacks

  1. [...] Pete Lacey also has a few thoughts on the use of digsig’s in Atom. [...]

  2. [...] Update: Pete Lacey also has a few thoughts on the use of digsig’s in Atom. [...]

  3. Stefan Tilkov's Random Stuff | May 26, 2007 at 3:01 am | Permalink

    Abdera Security…

    James Snell points to this developerWorks article by Nick Case which shows how to encrypt and sign Atom entries using Apache Abdera; Pete Lacey correctly notes that this addresses RESTful HTTP’s perceived message-level security shortcoming (and a…

  4. [...] Peter Lacey talks about how one could use Atom as a general envelope structure for any kind of transactional interactions, including executing an order. [...]

  5. [...] Today I read an article on Pete Lacey’s blog about using message-level security in REST applications (especially using the Atom Publishing Protocol). There was a comment by Bob McCormick that I found interesting. Bob pointed out that the protocol is vulnerable to replay attacks. [...]

  6. 1 Raindrop | July 9, 2007 at 3:15 pm | Permalink

    PETA: Protocols Enable Tampering Also…

    Matasano is featured in a preview of their Hacking Capitalism talk at Blackhat, which they say will describe various holes in FIX: You’d think electronic financial trading would be extra secure, but not so much: One of the most popular application-lay…

Post a Comment

Your email is never published nor shared. Required fields are marked *