7

I work with integration in the healthcare sector, where end-to-end security is important. We integrate with numerous SOAP services, and use the WS-security features to encrypt and sign requests and responses.

The requests and responses go through several middle tiers in our integration scenario. It is therefore important that the data itself is encrypted (message security). Using HTTPS (transport security) only protects the message until SSL termination.

We also integrate with REST-style services. AFAIK, there is no standard approach (like WS-security) to securing REST payloads.

Are there emerging standards for signing and encrypting REST payloads?

EDIT

Improve this question
3
  • 1
    SOAP and REST are software design, not communications protocols - how are you sending these SOAP and REST requests? Presumably you should secure this communication in the same way you'd secure any other - eg if you send HTTP request/responses, you should use HTTPS. Commented Oct 12, 2015 at 13:41
  • Yes we already use transport security (https). But my question is about message security i.e. encrypting the payload so the call is secure even after ssl termination. I'll clarify the q when I'm at a proper keyboard. Commented Oct 12, 2015 at 21:47
  • Same question over on Stack Overflow: stackoverflow.com/questions/9869828/… Commented Apr 2, 2018 at 16:51

3 Answers 3

Reset to default
2

I believe you are asking about identity propagation through a RESTful stack. In other words, you want to tie the request back to the original user so downstream systems can validate authorization on a per-user basis. I have also been researching this problem recently.

At heart, no, there is no standard defined for identity propagation for REST services. REST itself is not a standard, but rather an architectural pattern.

There are some libraries that provide integration with existing standards such as Kerberos (such as JAX-RS) or SAML via HTTP bindings.

Various approaches using JSON Web Tokens (JWT) are becoming popular, but this is more of a "roll-your-own" approach, which offers flexibility but at the cost of implementation risks. This is somewhat bleeding edge. The RFC for JWT was only approved in April, 2015.

Improve this answer
3
  • web tokens have always been popular they use the same logic as sessions and cookies essentially just implemented differently. if you want to be really clever you can even push the token as the session ID so you can program everything else as a standard backend as long as each call has the token within request. if you follow me Commented Oct 14, 2015 at 11:32
  • I recognize that web tokens provide a relatively simple solution, but I remain concerned that they can be susceptible to replay attacks and other abuse in the application stack as well as possible weaknesses in issuance all of which is dependent on particular implementations. I would be a lot more comfortable if JWTs were part of a complete protocol that standardized implementation and tied to directory services. Commented Oct 15, 2015 at 14:56
  • I think his concern is more about Confidentiality, integrity and authenticity of his payload. Commented Jul 12, 2016 at 12:22
0

If end to end security is a critical factor, the best approach to adopt is not trust anything in between. It then becomes irrelevant what protocols or APIs are used in between as they may or may not be secure. IMO this is a fair assumption - in any reasonably complex system with multiple middle tiers, there's no guarantee that their communications channels are properly secured. Or that they don't inadvertently cache data longer than they need, and as a consequence open a window where confidential data may be disclosed.

Suggestion:

  • Destination server generates a key pair (public + private keys). E.g. RSA with 4096 bits.
  • Distribute public key to the client. E.g. mobile clients could have the public key already packaged in the app.
  • The client encrypts the confidential data with the public key, and submits the cipher text. Only the destination server can decrypt the cipher text.
Improve this answer
1
  • While I love the motivation behind this answer, I believe it can only be applied to a limited number of use cases. The majority of uses cases require the data be usable by the intervening systems to deliver their functionality. The simplest example is simply formatting data retrieved from a database prior to sending the response to the user. If the database is to apply user specific access controls, it must know the users' identity, but the business logic and presentation layers need visibility into the database results to do their work to produce a formatted web page. Commented Oct 18, 2015 at 16:02
0

JWT is primarily for authentication, though you can customize the token to include roles and use it for authorization.

For signing and encrypting http messages, you can take a look at JSON Web Signature (JWS) and JSON Web Encryption (JWE). They are both RFCs that are part of the JSON Object Signing and Encryption (JOSE) framework.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.