feat(jans-cedarling): Policy Store: Parse Schema and Policies

[olehbozhok]

Prepare

• Read PR guidelines
• Read license information

---

Description

Target issue

link

closes #9568

Implementation Details

Added parsing a policy store with only schema key.
Currently, support loading only from memory

---

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 pull request focuses on enhancing the Cedarling application, a Rust-based local authorization service, by improving the handling of policy management and configuration, including the introduction of a new PolicyStoreConfig module, updates to the Cedarling::new() function to load the policy store, and changes to the Authz instance initialization.

Expand for full summary

Summary:

The code changes in this pull request are focused on enhancing the Cedarling application, a Rust-based local authorization service, by improving the handling of policy management and configuration. The key changes include:

1. Policy Store Configuration: The introduction of a new PolicyStoreConfig module, which allows for the configuration of the policy store source (e.g., loading policies from a JSON file).
2. Policy Store Loading: The Cedarling::new() function now loads the policy store using the load_policy_store() function, with appropriate error handling and logging.
3. Authorization Engine Initialization: The Authz instance is now created with the pdp_id (Policy Decision Point ID), log, and policy_store parameters, in addition to the AuthzConfig.
4. Documentation Updates: The changes include updates to the README files, providing more information about the "Init engine" and "Auth Engine" components of the Cedarling application.

From an application security perspective, the changes appear to be focused on improving the security and maintainability of the Cedarling application's policy management and authorization functionality. The introduction of the PolicyStoreConfig and the secure loading of the policy store are positive steps, as they allow for better control and management of the application's access control rules.

However, it's important to review the implementation details of the new modules and components to ensure that they are properly designed and implemented from a security perspective. This includes verifying input validation, secure data storage, and the overall integrity of the policy evaluation and authorization processes.

Files Changed:

1. jans-cedarling/cedarling/src/authz/README.md: This file provides an overview of the "Auth Engine" component, which is responsible for evaluating authorization requests.
2. jans-cedarling/Cargo.toml: The Rust crate dependencies have been updated to include the cedar-policy and base64 crates, which are likely used for policy management and data encoding/decoding, respectively.
3. jans-cedarling/README.md: The README file has been updated to remove the "Cedarling bindings" section, indicating that the project currently does not provide Python or WebAssembly bindings.
4. jans-cedarling/cedarling/examples/log_init.rs: This file has been modified to handle the new "PolicyStoreConfig" log type and the ability to specify a "memory" log type with a configurable time-to-live.
5. jans-cedarling/cedarling/src/authz/mod.rs: The Authz struct now takes a pdp_id (Policy Decision Point ID) and a policy_store parameter, indicating changes to the initialization of the authorization component.
6. jans-cedarling/cedarling/src/init/README.md: This new README file provides an overview of the "Init engine" component, which is responsible for reading bootstrap properties, loading Cedar Policies, and obtaining keys for JWT validation.
7. jans-cedarling/cedarling/src/init/mod.rs: This file introduces two new modules, cedar_schema and policy_store, which are likely responsible for handling the policy-related functionality.
8. jans-cedarling/cedarling/src/init/cedar_schema.rs: This file introduces a custom deserializer for the Cedar policy schema, which is an important security-related component.
9. jans-cedarling/cedarling/src/init/test_files/policy-store_schema_err_*.json: These files contain sample policy store schema definitions, which are important for understanding the application's access control rules.
10. jans-cedarling/cedarling/src/init/policy_store.rs: This new file introduces the PolicyStoreMap and PolicyStore data structures, which are responsible for managing the policy store.
11. jans-cedarling/cedarling/src/lib.rs: The Cedarling::new() function has been updated to load the policy store and handle any associated errors.
12. jans-cedarling/cedarling/src/log/log_strategy.rs: This file has been refactored to rename the LogType enum to LogTypeConfig.
13. jans-cedarling/cedarling/src/models/log_config.rs: The `

Code Analysis

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

Riskiness

🟢 Risk threshold not exceeded.

View PR in the DryRun Dashboard.

[duttarnab]

Please see the inline comments.

Please remove the following from README. We can add these once the bindings are added.

[duttarnab]

Rather than creating different enums for showing error messages, can we just make a single enum for all error messages inside \jans-cedarling\cedarling\src\models\enum\error.

for Example:

pub enum CedarlingApplicationError {
 #[error("{0}")]
    LoadPolicyStoreJsonParseError(#[from] serde_json::Error),
    #[error("store policy is empty")]
    LoadPolicyStoreWithEmptyPolicy,
    #[error("the `store_key` is not specified and the count on policies more than 1")]
    LoadPolicyStoreMoreThanOnePolicy,
    #[error("could not found policy by id: {0}")]
    LoadPolicyStorePolicyNotFound(String),
}

[olehbozhok]

I like the idea to return the error struct in functions that cover all possible error cases for only the current situation. Because it will be easier to maintain when application grows.

And If we have somethinglike CedarlingApplicationError
It will have all possible errors for all application.

And when we will be wanted to handle the error cases with match statement, it will be hard to understand what exactly cases current function returns. Because CedarlingApplicationError have all possible cases in the application.

[duttarnab]

And If we have something like CedarlingApplicationError
It will have all possible errors for all application.

This is what we practise in most of applications. We do not clutter our project with multiple Enums for error messages.

And when we will be wanted to handle the error cases with match statement, it will be hard to understand what exactly cases current function returns. Because CedarlingApplicationError have all possible cases in the application.

The naming convention of enum items should be sufficient of make its purpose clear. We don't need to make multiple error enums for this.

And I could see ErrorLoadPolicyStore in cedar_schem.rs and policy_store.rs. Code duplication does not make sense.

[duttarnab]

These errors should be handled using the CedarlingApplicationError enum . ( as discussed in #9575 (comment))

[olehbozhok]

We use it in the function parse_cedar_schema. It is wrapper to seamless deserialize cedar_policy::Schema from out JSON policy store.

Here how it is used in the macros:

#[derive(Debug, serde::Deserialize)]
pub struct PolicyStore {
    #[serde(deserialize_with = "parse_cedar_schema")]
    pub schema: cedar_policy::Schema,
}

In function, we can't return our custom type. Because we return generic of serde::Deserializer

pub(crate) fn parse_cedar_schema<'de, D>(deserializer: D) -> Result<cedar_policy::Schema, D::Error>
where
    D: serde::Deserializer<'de>,
{
...

Here is link with documentation about custom error handling in the serde.
So to return error from custom Deserializer we need to use implementation

impl de::Error for Error {
    fn custom<T: Display>(msg: T) -> Self {
        Error::Message(msg.to_string())
    }
}

Where error is casting to the string.

And actually it was made with

        serde::de::Error::custom(format!("{MSG_UNABLE_DECODE_SCHEMA_BASE64}: {}", err,))

and it was cowered by:

pub enum ErrorLoadPolicyStore {
    #[error("{0}")]
    JsonParce(#[from] serde_json::Error),
    ...

[duttarnab]

I was just saying that we should maintain uniformity of code everywhere. If we are taking the error messages as enum items somewhere then let's make it a practice everywhere. and we can easily convert an enum to a string. ref: https://stackoverflow.com/questions/32710187/how-do-i-get-an-enum-as-a-string.

[olehbozhok]

Otherwise, we need to create struct with RAW data and manually call a function to decode each field.
Which approach do you think is better?

[duttarnab]

as discussed, we can do something like the below to solve serde error handling

fn custom_deserialization_error(err: base64::DecodeError, errorEnum: ErrorLoadPolicyStore) -> de::value::Error {
    let message = errorEnum.to_string(); // Using the enum variant
    serde::de::Error::custom(format!("{}: {}", message, err))
}

[olehbozhok]

We discussed and decided to stay with const messages approach

[olehbozhok]

Please see the inline comments.

Please remove the following from README. We can add these once the bindings are added.

Removed

[nynymike]

The cedarling should not init if the schema is invalid.

[nynymike]

Ok

[Lilit0x]

requested changes have been made in #9584