feat(jans-lock): extend infrastructure for cedarling

[sokorototo]

Prepare

• Read PR guidelines
• Read license information

---

Implementation Details

• Correct DCR implementation
• Cleaned up commit tree
• Correct function signatures

---

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)

[dryrunsecurity]

Hi there 👋, @DryRunSecurity here, below is a summary of our analysis and findings.

DryRun Security	Status	Findings
Server-Side Request Forgery Analyzer	✅	0 findings
Configured Codepaths Analyzer	✅	0 findings
Secrets Analyzer	✅	0 findings
Authn/Authz Analyzer	✅	0 findings
SQL Injection Analyzer	✅	0 findings
Sensitive Files Analyzer	✅	0 findings
IDOR Analyzer	✅	0 findings

Note

🟢 Risk threshold not exceeded.

Change Summary (click to expand)

The following is a summary of changes in this pull request made by me, your security buddy 🤖. Note that this summary is auto-generated and not meant to be a definitive list of security issues but rather a helpful summary from a security perspective.

Summary:

The code changes in this pull request cover a wide range of updates across multiple files in the jans-lock/cedarling repository. The changes primarily focus on improving the security and reliability of the Cedarling application, which is a WebAssembly-based component that runs a local Cedar Engine.

The key security-related changes include:

1. Updating dependencies and removing potentially vulnerable libraries, such as the brotli crate.
2. Improving the handling and validation of OpenID configuration, policy store data, and access tokens to ensure the integrity and security of these critical components.
3. Implementing secure practices for dynamic configuration updates, policy store management, and authorization processes.
4. Enhancing error handling and logging to prevent the exposure of sensitive information.
5. Reviewing the use of WebAssembly (WASM) integration and ensuring the secure interaction between the Rust and JavaScript code.

Overall, the changes appear to be focused on strengthening the application's security posture, with a particular emphasis on the management of sensitive data, authentication and authorization mechanisms, and the secure integration of WASM technology.

Files Changed:

• .gitignore: The /samples directory has been added to the .gitignore file, which is a standard practice to exclude non-essential files from the Git repository.
• README.md: A new README file has been added, providing an overview of the Cedarling component and its key features, including the use of WebAssembly and dynamic policy updates.
• Cargo.toml: The project's dependencies have been updated, removing the brotli crate and adding new dependencies such as miniz_oxide, serde_json, and updated versions of existing dependencies.
• Cargo.lock: The lock file has been updated to reflect the changes in the Cargo.toml file.
• config.toml: The configuration file has been updated to include settings related to the decompression of the policy store, OpenID configuration, dynamic updates, and the policy store strategy.
• policy-store/default.json: The default policy store configuration file has been updated, defining the schema and entity types for various security-related entities, such as access tokens, user information tokens, and HTTP requests.
• src/authz/mod.rs: A new module has been introduced to handle authorization-related functionality, including the deserialization of various tokens.
• src/http.rs: The implementation of an HTTP client for the WASM-based application has been updated, with considerations around CORS, error handling, and response deserialization.
• src/sse.rs: A new module has been added to handle the setup and management of a Server-Sent Events (SSE) connection, which is used for dynamic configuration updates.
• src/lib.rs: The main library file has been refactored, with the introduction of new modules (authz, sse, and startup) and the simplification of the start() function.
• src/startup/statics.rs: This file manages the global state of the application, including the PolicySet, TrustedIssuer, and Schema objects.
• src/startup/mod.rs: This module handles the management of the OpenID configuration and the policy store data.
• tests/get-str.rs: A test case has been updated to use the cedarling::http module instead of the cedarling::utils module.
• src/startup/types.rs: New data structures related to OpenID authentication and dynamic client registration have been added.
• tests/fetch-open-id-config.rs: A new test case has been added to fetch the OpenID configuration from a hardcoded endpoint and log the fetched configuration.
• tests/fetch-schema.rs: The schema loading process has been updated to use a local JSON file instead of fetching it from a remote source.
• tests/test-btoa.rs: A new test case has been added to validate the js_btoa function, which is a Rust wrapper around the JavaScript btoa function for Base64 encoding.

Powered by DryRun Security

[SafinWasi]

Two main concerns:

• the tests are performing real HTTP requests. This should be done via mocking the HTTP server and responses.
• the tests themselves look incomplete, as they're not doing any comparison or assertions for the expected vs actual output.