With the rise of micro-services, REST communication is more popular than ever. But the communication between the different parts must also be performed in a secure way. First, we need to know if the user or system is allowed to call the JAX-RS endpoint. For this authentication part, self-contained tokens are the best option to not overload any of our services in the system. JWT which contains the authentication but also can contain the authorization info is ideal for this use-case. And secondly, we need guarantees that the message isn't altered, that we can have message integrity. For that part, we can use signatures like specified in the HTTP signature draft specification.

1. Secure JAX-RS
HTTPS://WWW.ATBASH.BE

2. • Verify caller
• No changed messages
• Performant

3. • C4J
• Senior Java Web Developer, Java Coach, Architect
• Atbash
• Open-Source developer - Java EE - Web Application Security - Testing
• Java EE Believer
@rdebusscher
@Atbash_EE
https://www.atbash.be
http://jsfcorner.blogspot.be
http://javaeesquad.blogspot.be
W H O A M I
RUDY DE BUSSCHER

4. What is Secure Rest?
A G E N D A

5. S H I F T T O R E S T

6. • REST == JSON communication over HTTP
(ignoring hyperText)
• Why REST?
• No special/specific clients and servers
• HTTP operations like get, post, delete and URI
identified
• Simple, lightweight, fast, ...
S H I F T T O R E S T

7. Confidentiality : Shield data but also verify the sender
Integrity : Trustworthiness, can data be altered in
transit?
Availability : Systems up (but also counter DDOS attacks)
I N F O R M A T I O N
S E C U R I T Y

8. JAX-RS (Rest) SOAP
On top of HTTP protocol, lightweight Heavy weight due to metadata
Multiple data formats (JSON, XML, ...) XML only
Easier, loosely Harder, contract based
Security and authorization are part of the
protocol

9. WS-security
• Confidentiality
• Integrity
• end-to-end protection of message
• process to process
• Certificates, SAML, XML Signatures, Encryption, ...
S E C U R I T Y W I T H I N S O A P

10. • Only capabilities underlying protocol
• HTTPS = Confidentiality + Integrity
• Encrypted
• Message digest (unaltered in transit)
• Few major things are missing
S E C U R I T Y W I T H J A X - R S

11. • HTTPS = confidentiality (integrity)
• But
• Sender verification?
• End to end encryption?
• Server to server only (not the process on the
server)
S E C U R I T Y W I T H J A X - R S

12. Demo

13. • Verify sender
• end-to-end protection
• (encryption) -> https
G O A L S
SECURE
REST

14. W H Y H T T P S N O T E N O U G H

16. Verify Sender
A G E N D A
End-to-End protection
Some loose ends
Conclusion

17. HOW DOES EACH HOP KNOW THE END USER?

18. U S I N G P A S S W O R D ?
• Basic Auth for each request (stateless!)
• 3000 TPS on LDAP
• Backend through IP whiteListing?
• Each hop
• 12000 TPS on LDAP!
• DDOS attacks -> LDAP down!

19. • session id = opaque
• Backend needs to lookup info
• Not LDAP but "idHop" is overloaded
S E S S I O N S ?

20. T O K E N S
• Like a long id
• Token contains all info (authc, authz)
• Signed!!
• OpenId Connect - idToken
• MicroProfile JWT Auth Token

21. T O K E N S O L U T I O N

22. • Token = data + signing
• Tamper with data -> signing detects this
• token created by Mallory -> Signing not correct
T O K E N P R O T E C T I O N

23. S I G N I N G

24. J W T

25. Demo

26. End-to-End protection
A G E N D A
Some loose ends
Conclusion
Verify sender

27. • 99% use cases -> guarantee it is not modified
• Personal, medical info -> encryption
E N C R Y P T I O N V S S I G N I N G

28. E N D - T O - E N D P R O T E C T I O N
- Content protected from Process to Process
- No intermediate intervention possible

29. E N D - T O - E N D P R O T E C T I O N
APPLICATION LAYER SECURITY

30. A L S O J W T ?
• REST payload as JWT Payload?
• Signed
• Created and verified by process -> E2E
• Payload is not easy readable anymore (tracing/routing
on server side)

31. H T T P S I G N A T U R E S
• Standard by Internet Engineering Task Force
(IETF)
• Draft
• Signatures variant (Authentication variant exists)
• Non 'invasive'

32. H T T P - S I G H O W ?
• Additional Header
• Signature : ...
• HTTP friendly
• Signature : keyId="rsa-key-1",algorithm="rsa-
sha256",headers="(request-target) host date digest content-
length",signature="Base64(RSA-SHA256(signing string))"

33. H T T P - S I G P A R A M E T E R S
• Headers : What is used in signature 'calculation'
• header name of pseudo header (request target =
method + URL path)
• Digest -> Hash of message body
• keyId : Id of the RSA key for Signature
• algorithm : What algorithm used for signature
• signature : operation result

34. Demo

35. Some loose ends
A G E N D A
Conclusion
Verify sender
End-to-end protection

36. C O M B I N I N G W I T H A U T H C
• RSA key for signature
• Can be used to identify remote
• Use it with Authorization header
• Authorization : Signature keyId="...
• Or combine it with OAuth2 / OpenId Bearer header
• Authorization : Bearer ey...
• Signature : keyId="...

37. J A V A S C R I P T F R A M E W O R K S
Can browser/javaScript keep secrets private?
Most experts agree it is not possible
XSS scripts

38. • Good start
• Standardised correct code
• PRNG and BigInt
• No advice on what to use when
• Beware of storing keys
• Local storage is not safe
• Use Password encrypted formats
• Not all browsers support it (some only old variants)
W E B C R Y P T O G R A P H Y A P I

39. Conclusion
A G E N D A
Verify sender
End-to-End protection
Some loose ends

40. T A K E A W A Y S
• JAX-RS has no intrinsic security aspects
• JWT ideal to keep Authentication / Authorization
info
• SSL (HTTPS) does not eliminate need for encryption
• HTTP signatures ideal for end to end protection of
content
• Browser (JavaScript) still issue in keeping things
private

41. • Webshop
• https://github.com/rdebusscher/secure-rest
• Http Signature Framework
• https://github.com/atbashEE/rest-signatures
C O D E

42. Q & A