docs(jans-cedarling): shorten conditional

[SafinWasi]

Prepare

• Read PR guidelines
• Read license information

---

Description

Target issue

closes #10810

Implementation Details

---

Test and Document the changes

N/A

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.

[olehbozhok]

Looks like you don't need to remove attribute has because it can cause error in evaluating this rule

[olehbozhok]

You must check for presence of nested, optional attributes one layer at a time. For example, to check for the presence of principal.custom.project where both custom and project are optional, you must first check if principal has a custom attribute and then check that it principal.custom has a project attribute:

https://docs.cedarpolicy.com/policies/syntax-operators.html#operator-has

[olehbozhok]

I don't agree to make the rule shorten, but approve if Michael agree

[nynymike]

Let's consider ergonomic syntax... is your policy more readible? Is it much faster? If so, how much? If it's not more readible, or faster, what is the advantage? Please don't just say "I don't like it"--give me a reason please.

[syntrydy]

@nynymike

1. It violates Cedar's fundamental safety principles by making assumptions about the data structure without verification. In Cedar, when we access optional attributes using bracket notation like principal["access_token"] , we're essentially saying "I'm certain this attribute exists" - but we can't actually be certain.
   This is particularly dangerous in authorization policies where unexpected attribute access could lead to security vulnerabilities.

2. When we chain attribute access like ((principal["access_token"])["scope"]) , we're creating a cascade of potential failure points. If either access_token or scope is missing, this could lead to a runtime error. This is especially problematic because Cedar policies need to be reliable and deterministic - a policy failure due to unsafe attribute access could result in either incorrectly granting or denying permissions, both of which are serious security concerns.

3. Cedar deliberately requires explicit handling of optional attributes using the has operator to force policy authors to think about and handle edge cases. The above change goes against Cedar's philosophy of making attribute access safety explicit rather than implicit. This makes the policy more fragile and harder to maintain because it's not clear from reading the code whether these attributes are optional or required.

[nynymike]

Ok, I'm going to post this to the Cedar slack. It seems like we're sacrificing ergonomic syntax.

[SafinWasi]

According to cedar developers, the ergonomic way to do this is to use dot notation instead of square bracket syntax. By using the extended RHS syntax of the has operator, we can implicitly test the existence of both access_token and scope before the second conditional is evaluated.

@id("allow_one")
permit(
  principal is Jans::Workload,
  action == Jans::Action::"GET",
  resource is Jans::HTTP_Request
)
when {
    principal has access_token.scope &&
    principal.access_token.scope.contains("profile")
};

On cedar-policy-cli 4.3.1:

$ cedar validate --schema cedarling_core.cedarschema --policies policy.cedar
  ☞ policy set validation passed
  ╰─▶ no errors or warnings

[nynymike]

Looks better!