The document discusses security features in JAX-RS for RESTful web services, highlighting that while HTTPS provides confidentiality and integrity, it lacks sender verification and end-to-end protection. It also introduces the use of JWTs for authentication and authorization, and suggests implementing HTTP signatures for content protection. Key takeaways include the need for additional security measures beyond SSL to ensure comprehensive protection in REST architectures.

1. Secure JAX-RS

2. • Verify caller
• No changed messages
• Performant

3. What You’ll Learn Today
• Are all security features built into JAX-RS?
• Is HTTPS sufficient
• Verify sender with JWT
• Message integrity with HTTP Signatures.

4. Rudy De Busscher
• Payara
• Service team
• JSR-375
• Java EE Security API Expert group member
• Committer in Eclipse EE4J groups
• Java EE Believer
@rdebusscher
https://blog.payara.fish/
https://www.atbash.be

5. AGENDA
What is Secure Rest?

6. SHIFT TO REST

7. SHIFT TO REST
• 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, ...

8. Information security
• Confidentiality : Shield data but also verify the sender
• Integrity : Trustworthiness, can data be altered in transit?
• Availability : Systems up (but also counter DDOS attacks)

9. 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

10. Security within SOAP
• WS-security
• Confidentiality
• Integrity
• end-to-end protection of message
• process to process
• Certificates, SAML, XML Signatures, Encryption, ...

11. Security with JAX-RS
• Only capabilities underlying protocol
• HTTPS = Confidentiality + Integrity
• Encrypted
• Message digest (unaltered in transit)
• Few major things are missing

12. • HTTPS = confidentiality (integrity)
• But
• Sender verification?
• End to end protection?
• Server to server only (not the process on the server)
Security with JAX-RS

13. SECURE
REST
GOALS
• Verify sender
• end-to-end protection
• (encryption) -> https

14. Demo

15. Why HTTPS not enough

17. AGENDA Verify Sender
End-to-End protection
Some loose ends
Conclusion

18. HOW DOES EACH HOP KNOW THE END USER?

19. using Password?
• Basic Auth for each request (stateless!)
• 3000 TPS on LDAP
• Backend through IP whiteListing?
• Each hop
• 12000 TPS on LDAP!
• DDOS attacks -> LDAP down!

20. Sessions?
• session id = opaque
• Backend needs to lookup info
• Not LDAP but "idHop" is overloaded

21. Tokens
• Like a long id
• Token contains all info (authc, authz)
• Signed!!
• OpenId Connect - idToken
• MicroProfile JWT Auth Token

22. Token Solution

23. Token PROTECTION
• Token = data + signing
• Tamper with data -> signing detects this
• token created by Mallory -> Signing not correct

24. Signing

25. JWT

26. Demo

27. AGENDA Verify Sender
End-to-End protection
Some loose ends
Conclusion

28. End-To-END PROTECTION
• Content protected from Process to Process
• No intermediate intervention possible

29. APPLICATION LAYER
SECURITY
End-To-End protection

30. also JWT?
• REST payload as JWT Payload?
• Signed
• Created and verified by process -> E2E
• Payload is not easy readable anymore
(tracing/routing on server side)

31. HTTP Signatures
• Standard by Internet Engineering Task Force (IETF)
• Draft
• Signatures variant (Authentication variant exists)
• Non 'invasive'

32. HTTP-Sig How?
• 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. Http-Sig parameters
• 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. AGENDA Verify Sender
End-to-End protection
Some loose ends
Conclusion

36. Combining with Authc
• 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. JavaScript Frameworks
• Can browser/javaScript keep secrets private?
• Most experts agree it is not possible
• XSS scripts

38. Web Cryptography API
• 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)

39. AGENDA Verify Sender
End-to-End protection
Some loose ends
Conclusion

40. Take aways
• JAX-RS has no intrinsic security aspects
• JWT ideal to keep Authentication / Authorization info
• SSL (HTTPS) does not eliminate need for E2E Protection
• HTTP signatures ideal for end to end protection of content
• Browser (JavaScript) still issue in keeping things private

41. Code
• Webshop
• https://github.com/rdebusscher/secure-rest
• Http Signature Framework
• https://github.com/atbashEE/rest-signatures

42. Q & A

43. Thank You
Not using the Payara Platform yet? Download the open
source software: Payara Server or Payara Micro
https://payara.fish/downloads
Need support for the Payara Platform?
https://payara.fish/support