Encryption support

[pwmorreale]

A useful enhancement to OPA would be builtin functions enabling support for JOSE.

The use case is simply providing a means for a non-secure application to provide secret input to OPA. As a configuration data format, JSON dovetails quite nicely with OPA and rego, enabling support for encrypted tokens provides a system with some guarantees regarding non-repudiation, confidentiality, and integrity.

From an API perspective, something similar to the current io,jwt.decode.verify() builtin might work well. From a user perspective, access to the jwt components after successful decrypt/verification should be sufficient. Since this is a security issue, direct control (within the api?) on whether detected errors are written to logs would be desirable.

Suggested supported algorithms include:

• A256KW
• A256GCMKW
• RSA-OAEP-256
  would be a good start.

[tsandall]

@pwmorreale thanks for opening this. Just for my understanding, the non-secure application will supply the encrypted token to OPA in the input and the policy should be able to verify, decrypt, and decode the token. What's currently missing from OPA is:

• Ability to decrypt
• Guarantee that sensitive data is not being leaked (via logs, error responses, etc.)

[pwmorreale]

Precisely. The jwt enters into OPA via an input stream. The non-secure application is merely the transport for passing the secure datum to OPA.

Logging presents its own set of issues... ;-) Given that the jwt in question is secure, logging it is not a security issue. That said, jwt's can be several K's of bytes long and both hammer performance as well as fill up persistent resources. (most especially under a DOS attack)

I think a longer term solution will be a more flexible logging implementation that allows the admin to configure which fields are included in a log msg, as well as (perhaps) a max byte count per log msg.

But that is another issue for another day... :-)

[BenderScript]

Looked at this and have a q: where would the necessary private/symmetric keys to decrypt the contents (for each JWT) come from?

[pwmorreale]

well... that's just data, right? Same place the cert used for verifying the jwt signature comes from.

The policy bundle would be the likely place.

[BenderScript]

Please allow me to expand. The cert to verify comes as part of the built in functions. I believe the algorithms you suggested are based pub/pvt keys (https://tools.ietf.org/html/rfc7516, https://tools.ietf.org/html/rfc7520), but in general there is the issue of symmetric keys. Should they appear in the configuration? Come from Env variables? What would be your suggestion?

[BenderScript]

Please assign to @repenno

[pwmorreale]

The keys could come from either. In the configuration scenario, one has the option to add authz security to the configuration to control access to the data document.

[stale]

This issue has been automatically marked as inactive because it has not had any activity in the last 30 days.