Secure JAX-RS

• Verify caller
• No changed messages
• Performant

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.

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

AGENDA
What is Secure Rest?

SHIFT TO REST

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

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)

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

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

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

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

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

Demo

Why HTTPS not enough

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

HOW DOES EACH HOP KNOW THE END USER?

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!

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

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

Token Solution

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

Signing

JWT

Demo

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

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

APPLICATION LAYER
SECURITY
End-To-End protection

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)

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

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))"

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

Demo

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

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="...

JavaScript Frameworks
• Can browser/javaScript keep secrets private?
• Most experts agree it is not possible
• XSS scripts

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)

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

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

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

Q & A

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