refactor(jans-cedarling): improve WASM compatibility

[rmarinn]

Prepare

• Read PR guidelines
• Read license information

---

Description

This PR improves WASM compatibility by:

• using the chrono crate which has WASM support instead of std::time for getting the time.
• using replacing reqwest::blocking::Client with reqwest::Client.

Target issue

target issue: refactor(jans-cedarling): improve WASM compatibility #10330

closes #10330

Implementation Details

• the HttpClient create will store a reference to a tokio runtime which it will use to make async requests so compiling to WASM would be possible.

---

Test and Document the changes

• Static code analysis has been run locally and issues have been fixed
• Relevant unit and integration tests have been added/updated
• Relevant documentation has been updated if any (i.e. user guides, installation and configuration guides, technical design docs etc)

Please check the below before submitting your PR. The PR will not be merged if there are no commits that start with docs: to indicate documentation changes or if the below checklist is not selected.

• I confirm that there is no impact on the docs due to the code changes in this PR.

[dryrunsecurity]

DryRun Security Summary

The provided GitHub pull request contains changes across multiple files in the jans-cedarling and sparkv Rust projects, primarily focused on improving the handling of time-related functionality, such as the use of the chrono crate for managing dates and durations, and the introduction of time-to-live (TTL) support in the SparKV key-value store, without introducing any obvious security vulnerabilities.

Expand for full summary

Summary:

The provided GitHub pull request contains a series of changes across multiple files in the jans-cedarling and sparkv Rust projects. The changes primarily focus on improving the handling of time-related functionality, such as the use of the chrono crate for managing dates and durations, and the introduction of time-to-live (TTL) support in the SparKV key-value store.

From an application security perspective, the changes do not introduce any obvious security vulnerabilities. The updates appear to be focused on improving the reliability, performance, and maintainability of the code, with a particular emphasis on ensuring that time-related operations are handled correctly and securely.

Some key security-related aspects of the changes include:

1. Dependency Updates: The introduction of the chrono crate is a positive change, as it provides a well-established and secure way of handling date and time-related functionality, which is an important consideration for any application.

2. Expiration Management: The changes to the ExpEntry and SparKV structures demonstrate a well-designed approach to managing the expiration of key-value pairs, including the use of a binary heap to efficiently track and remove expired entries.

3. Capacity and Size Constraints: The enforcement of limits on the number of items and the size of each item in the SparKV struct helps mitigate potential denial-of-service attacks or resource exhaustion issues.

4. Error Handling and Logging: The code includes robust error handling and logging mechanisms, which can be important for security monitoring and incident response.

Overall, the changes in this pull request appear to be focused on improving the functionality and reliability of the jans-cedarling and sparkv projects, without introducing any significant security concerns. As an application security engineer, I would recommend closely reviewing the usage of the updated components within the broader application context to ensure that there are no unintended security implications.

Files Changed:

1. jans-cedarling/Cargo.toml: Added the chrono dependency.
2. jans-cedarling/cedarling/Cargo.toml: Updated dependencies, including removing time and adding chrono and tokio.
3. jans-cedarling/cedarling/src/jwt/http_client.rs: Improved the HttpClient struct with asynchronous functionality and better error handling.
4. jans-cedarling/cedarling/src/jwt/jwk_store.rs: Implemented a secure and robust JSON Web Key (JWK) store.
5. jans-cedarling/cedarling/src/log/memory_logger.rs: Updated the MemoryLogger to use the chrono crate and improve the handling of log entries.
6. jans-cedarling/cedarling/src/jwt/key_service.rs: Improved the KeyService module for managing and retrieving decoding keys for JWT validation.
7. jans-cedarling/cedarling/src/log/stdout_logger.rs: Updated the StdoutLogger to use the chrono crate for timestamp handling.
8. jans-cedarling/cedarling/src/log/log_entry.rs: Updated the LogEntry struct to use the chrono crate for timestamp handling.
9. jans-cedarling/sparkv/Cargo.toml: Added the chrono dependency.
10. jans-cedarling/sparkv/README.md: Updated the README file to reflect changes in the set_with_ttl() method.
11. jans-cedarling/cedarling/src/log/test.rs: Removed unnecessary imports and updated timestamp handling.
12. jans-cedarling/sparkv/src/config.rs: Updated the Config struct to use chrono::Duration.
13. jans-cedarling/sparkv/src/kventry.rs: Updated the KvEntry struct to use chrono::DateTime<Utc> for expiration time.
14. jans-cedarling/sparkv/src/expentry.rs: Updated the ExpEntry struct to use chrono for expiration time handling and comparison.
15. jans-cedarling/sparkv/src/lib.rs: Introduced TTL support and expiry

Code Analysis

We ran 9 analyzers against 15 files and 0 analyzers had findings. 9 analyzers had no findings.

View PR in the DryRun Dashboard.

[djellemah]

Locally, there are build failures with cargo test --target wasm32-wasip1 and cargo test --target wasm32-unknown-unknown. Is that expected right now?

Looks to me the cause is jsonwebkey, which pulls in an older version of jsonwebtoken which then pulls in an older version of ring.

[rmarinn]

Locally, there are build failures with cargo test --target wasm32-wasip1 and cargo test --target wasm32-unknown-unknown. Is that expected right now?

Yeah... turns out we need to change more things (other than the jsonwebkey issue) before it compiles correctly which is why i converted this to draft for now.

Looks to me the cause is jsonwebkey, which pulls in an older version of jsonwebtoken which then pulls in an older version of ring.

we're only really using jsonwebkey for tests so I'll probably just replace that when I get the time.

[abaghinyan]

maybe it should be better to use DeserializeText instead of DeserializeJson here

[abaghinyan]

It's a good practice to add a timeout in during an http request like:

let client = Client::builder()
.timeout(Duration::from_sec(20))
.build()
.map_err(HttpClientError::Initialization)?;

[abaghinyan]

In general it's better to use async then block_on. Here you can do something like :

let resp_json = self
            .resp
            .json::<T>()
            .await
            .map_err(HttpClientError::DeserializeJson)?;
        Ok(resp_json)

Moreover, you can remove the lifetime parameter <'rt> from Response.