feat: JWT verification builtins (#94)

[wetpeanuts]

Implemented:

• Implemented builtins: io.jwt.[decode|decode_verify|verify_xxxxx] (except verify_eddsa)
• Fully passed OPA tests: jwtbuiltins, jwtverifyhs[256|384|512], jwtverifyrsa
• Partially passed OPA tests: jwtdecodeverify (the ones that leverage io.jwt.verify_eddsa and io.jwt.encode_sign still do not pass)
• In order to enable customization of the crypto libraries behind JWT verification algorithms, this implementation introduces JWT Backend trait that describes common interface for JWT verification. The trait can be implemented using variable libraries, depending on user needs. The exact trait implementation is selected based on a feature provided to compiler. Currently only 1 inplementation of the JWT Backend is available (leverages OpenSSL as underlying crypto lib).

To be implemented in the follow up PRs:

• verify_eddsa support and token encoding builtins.

Note that I've also modified the implementation for opa tests in order to be able to run each test separately, not sure if it really belongs here.

Looking forward for a feedback

[wetpeanuts]

@microsoft-github-policy-service agree

[anakrish]

Hey @wetpeanuts,

Thank you for the contribution!

1. Some of the failures are due to out of date lock files. There is now an experimental cargo xtask update-deps that should update the relevant lock files once the root Cargo.toml has been changed. If that doesn't work, each folder within bindings needs to be updated manually by running cargo update.
2. It looks like the windows build runners don't have openssl installed. That causes the other failures.
   Maybe we could start off by disabling this feature in the bindings, make sure that it works with Rust only usage, and then later enable it for the bindings.
3. Can we ensure that we are using OpenSSL 3.x? Anything below is not approved for use at MSFT.

[wetpeanuts]

Hey @anakrish

Thank you for the feedback

1. Guess I need to rebase to the latest main and use it. I'll give it a try.
2. I actually plan to introduce another Rust only JWT backend in the next iteration and use it as default. I agree that using OpenSSL by default is probably not the best idea since it might be missing in some environments.
3. I'll check how we can ensure using OpenSSL 3.x.

[anakrish]

Hey @wetpeanuts,

Given MSFTs constraints on FIPS certification etc, we will likely want OpenSSL 3.x as the default. But having a rust only option is also good for other consumers of the crate.

Another approach to consider is whether a registration mechinasm can be provided to install an instance of the trait for use as the crypto implementation.

[wetpeanuts]

Hello @anakrish,
I've been quite loaded at the end of the year, now I am back on the project. I've rebased to the latest main and faced an error when running some OPA tests:
error: line exceeds maximum column width of 1024
which is thrown by lexer.
The problem is that some tests (like this one) check quite large JWTs that do not satisfy this limitation. Could you advise on better approach to overcome this limitation? Should I maybe introduce some exceptions for this check in the test environment?

[anakrish]

Hey @wetpeanuts,

Gald to have you back. The data field could be used to specify the JWT objects.

regorus/tests/interpreter/cases/data/tests.yaml

Line 6 in 5afbd96

data:

[anakrish]

Also note that we are hardening regorus via strict clippy warnings. Do take a look at this: #513 (comment)

[wetpeanuts]

@anakrish Thank you for the hint. The data field you are talking is about regorus test coverage if I understand it correctly, is it correct? The problem for me lies in the original OPA tests from original OPA repo, that are fetched and being fed to the regorus engine in the opa test. With this limitation they do not pass. Since I assume changing the original test coverage is not an option I'm trying to find a way to overcome this on regorus side.

[anakrish]

@wetpeanuts Ah. In that case, we could add capability (available only when test feature is enabled) to suppress these checks.