refactor: new policies

[SafinWasi]

Must be merged after JanssenProject/jans#12833

Summary by CodeRabbit

• New Features

  • Added 17+ new access control policies covering read, write, execute, search, compare, monitor, tag, and share operations across multiple roles.
  • Implemented conditional access controls based on network type, geolocation, device health, email domain, and fraud indicators.

• Updates

  • Refined existing policy with more specific resource type constraints.
  • Expanded trusted issuer configuration and schema definitions for enhanced token metadata handling.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR introduces 17 new access control policy definitions and modifies 1 existing policy within a policy management system. Two configuration JSON files are updated to register the new policies, expand trusted issuer metadata, and enhance token metadata structures with user tracking and role-based principal mappings.

Changes

Cohort / File(s)	Summary
JSON Configuration Files 449805c83e13f332b1b35eac6ffa93187fbd1c648085.json	Updated existing policy allow_teacher to allow_teacher_secretdocument with refined policy content. Added 17 new policy entries across various permission scenarios (read, write, execute, monitor, search, tag, compare, share). Expanded trusted_issuers with new issuer key and enriched token_metadata fields (user_id, token_id, workload_id, role_mapping, claim_mapping, principal_mapping). Replaced schema field with expanded payload.
JSON Schema Update 6d9f73b2d44ad4e7aa8f1182cde9f72dcbaa244f4327.json	Updated schema field with new base64-encoded content; all other fields remain unchanged.
Policy Rule Files (Permit Rules) tarpDemo/91b2611a1ea9859cb7ce780ca16adf3b2a68f892786a.policy, tarpDemo/6e46e36071466cc37c0e9bbd65f16c51ea2ab152c6fc.policy, tarpDemo/e76eb1853f0c6a199ca383cd9714e0113dfd851e079a.policy, tarpDemo/b5111ecf0d218da2cdbece83aeb77cb6b479d3b5d85c.policy, tarpDemo/c4729e4ab456b4c8e74102593e5b32e04176bc837cc5.policy, tarpDemo/4ab79a92feac06a1a005373b741ed50e07d23d98f9a5.policy, tarpDemo/13b34711a196f382ade96677cefd513a2a6deff1b949.policy, tarpDemo/fe84f983188f1639a03ed77c0753fc893fbe0d4cf155.policy, tarpDemo/9e2f1520bd292765609e8ce57add8d3c134e3a91759d.policy, tarpDemo/e459eba6691d141497dd1317e44d3d5b3bdd9fd65150.policy, tarpDemo/50c0ea31a9ed25a575b7538dec38cb953431651e7bec.policy	New permit-based access control policies enabling various actions: user_can_read, user_can_search, user_can_execute, user_can_monitor, user_can_compare, user_can_tag, admin_can_write_to_application, editor_can_share, security_admin_can_write_to_secretdocument, user_can_read_if_confidential_role, user_can_read_if_email_is_example.
Policy Rule Files (Forbid Rules) tarpDemo/28e83add6e203af0d3814f06228e45a0eeb5c1269b08.policy, tarpDemo/420184da127304d1b2898761893a974096f6dbade45a.policy, tarpDemo/689edd369c276afb5a163119dcd92c74196a4e0c7bdb.policy, tarpDemo/c367d06f19af8db1ec69354044334c799ff4cd2021ae.policy, tarpDemo/f38f10e80c6f429153cf97781a4c6bcf29761a04259f.policy, tarpDemo/fe83e4b2338614b970559ce4141b6d3e60559d79282c.policy, tarpDemo/870eaec25d9c8e9a642c4ed4d08b1ad480e6bc1348c7.policy	New forbid-based access control policies restricting actions based on contextual conditions: user_cannot_write_from_restricted_country (geolocation), user_cannot_execute_on_public_network (network type), user_cannot_read_if_compromised (device health), user_cannot_read_if_fraudulent (fraud indicators), cannot_write_if_not_admin (role check), user_can_read_in_corp_network (network context), user_cannot_write_to_secretdocument.
Updated Policy Rule tarpDemo/76acfe86fb09731682f92c4fbf7d2e066813ce639404.policy	Policy identifier updated from allow_teacher to allow_teacher_secretdocument. Resource constraint refined from bare resource reference to typed constraint resource is Jans::SecretDocument.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'refactor: new policies' is vague and overly generic. It mentions 'refactor' but the changes are primarily feature additions (16+ new policy files), not refactoring. The term 'new policies' is too broad to convey meaningful detail about what was changed.	Consider a more specific title such as 'feat: add access control policies for demo' or 'feat: add 16 TARP policies with context and role-based rules' to better describe the actual change.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ossdhaval]

Hi @SafinWasi

Policies add much needed variety of examples to the demo 👍

Before merging, you'll need to take care of Unverified commits and DCO.

[SafinWasi]

@ossdhaval unfortunately commits authored under Agama Lab are not GPG signed as that functionality is beyond the capacities of github app installation.

[coderabbitai]

Actionable comments posted: 13

📜 Review details

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 75507b5 and 75a1bfd.

📒 Files selected for processing (21)

• 449805c83e13f332b1b35eac6ffa93187fbd1c648085.json
• 6d9f73b2d44ad4e7aa8f1182cde9f72dcbaa244f4327.json
• tarpDemo/13b34711a196f382ade96677cefd513a2a6deff1b949.policy
• tarpDemo/28e83add6e203af0d3814f06228e45a0eeb5c1269b08.policy
• tarpDemo/420184da127304d1b2898761893a974096f6dbade45a.policy
• tarpDemo/4ab79a92feac06a1a005373b741ed50e07d23d98f9a5.policy
• tarpDemo/50c0ea31a9ed25a575b7538dec38cb953431651e7bec.policy
• tarpDemo/689edd369c276afb5a163119dcd92c74196a4e0c7bdb.policy
• tarpDemo/6e46e36071466cc37c0e9bbd65f16c51ea2ab152c6fc.policy
• tarpDemo/76acfe86fb09731682f92c4fbf7d2e066813ce639404.policy
• tarpDemo/870eaec25d9c8e9a642c4ed4d08b1ad480e6bc1348c7.policy
• tarpDemo/91b2611a1ea9859cb7ce780ca16adf3b2a68f892786a.policy
• tarpDemo/9e2f1520bd292765609e8ce57add8d3c134e3a91759d.policy
• tarpDemo/b5111ecf0d218da2cdbece83aeb77cb6b479d3b5d85c.policy
• tarpDemo/c367d06f19af8db1ec69354044334c799ff4cd2021ae.policy
• tarpDemo/c4729e4ab456b4c8e74102593e5b32e04176bc837cc5.policy
• tarpDemo/e459eba6691d141497dd1317e44d3d5b3bdd9fd65150.policy
• tarpDemo/e76eb1853f0c6a199ca383cd9714e0113dfd851e079a.policy
• tarpDemo/f38f10e80c6f429153cf97781a4c6bcf29761a04259f.policy
• tarpDemo/fe83e4b2338614b970559ce4141b6d3e60559d79282c.policy
• tarpDemo/fe84f983188f1639a03ed77c0753fc893fbe0d4cf155.policy

🔇 Additional comments (15)

tarpDemo/c4729e4ab456b4c8e74102593e5b32e04176bc837cc5.policy (1)

1-6: LGTM! Simple and well-structured policy.

The policy correctly defines a permit rule allowing users to perform Compare actions on applications. The Cedar syntax is correct and the policy logic is straightforward.

tarpDemo/e459eba6691d141497dd1317e44d3d5b3bdd9fd65150.policy (1)

1-6: Sensitive resource access granted - verify role assignment process.

This policy grants read access to SecretDocument for users in the "confidential" role. Ensure that the assignment of users to the "confidential" role is properly controlled and audited, as this grants access to sensitive documents.

tarpDemo/4ab79a92feac06a1a005373b741ed50e07d23d98f9a5.policy (1)

1-6: LGTM! Clean policy definition.

The policy correctly defines a permit rule for users to tag applications. The syntax is correct and the logic is clear.

tarpDemo/91b2611a1ea9859cb7ce780ca16adf3b2a68f892786a.policy (1)

1-6: Broad permission granted - verify this aligns with security requirements.

This policy allows all users to read applications without any conditions. Ensure this level of access is intended and aligns with the principle of least privilege for your security model.

tarpDemo/c367d06f19af8db1ec69354044334c799ff4cd2021ae.policy (1)

1-9: Good security practice with explicit deny rule.

This forbid policy correctly implements fraud-based access denial. The syntax properly checks for the existence of fraud_indicators before accessing it. In Cedar, forbid policies take precedence over permit policies, ensuring that fraudulent requests are blocked even if other policies would permit access.

Verify that the "high_risk" string value matches the fraud indicator values set by your backend application when populating the request context.

tarpDemo/fe84f983188f1639a03ed77c0753fc893fbe0d4cf155.policy (1)

3-3: Standardize role naming conventions across policies.

This policy uses capitalized role name "Editor", but other policies use inconsistent conventions: "confidential", "admin", and "security-admin" (lowercase), while "Teacher" and "Student" are capitalized. Apply a consistent naming convention (all lowercase or all capitalized) across all role definitions to prevent runtime authorization mismatches.

tarpDemo/fe83e4b2338614b970559ce4141b6d3e60559d79282c.policy (1)

6-9: Context attribute population and security validation are outside the scope of this policy file and must be verified at the enforcement point level.

This policy's defensive check (context has network &&) is sound, but the three underlying concerns cannot be verified within this quickstart repository because it contains only policy definitions and schema. The enforcement point implementation—which is responsible for populating context attributes, ensuring network classification security, and validating the "corp" designation—is not included in this repository. These validations need to be confirmed in the Cedarling framework or the consuming application.

6d9f73b2d44ad4e7aa8f1182cde9f72dcbaa244f4327.json (1)

15-15: Schema includes all required types and properly supports new policies and actions.

Verification confirms all components are correctly defined:

1. All new actions (Compare, Share, Tag, Monitor, DELETE, Execute, GET, HEAD, PATCH, POST, PUT, Read, Search, Write) are present with proper appliesTo definitions
2. Resource types Application and SecretDocument are properly defined; Application includes attributes (app_id, name, url)
3. Context attributes required for conditional policies are all defined: current_time, device_health, fraud_indicators, geolocation, network, network_type, operating_system, tokens, user_agent
4. Role entity type is properly included and referenced

tarpDemo/76acfe86fb09731682f92c4fbf7d2e066813ce639404.policy (1)

5-5: Breaking change: Resource constraint narrowed to SecretDocument.

The resource constraint changed from a generic resource to resource is Jans::SecretDocument, which significantly narrows the policy scope. Verify that this is intentional and that Teacher role access to other resource types (if needed) is covered by other policies.

tarpDemo/9e2f1520bd292765609e8ce57add8d3c134e3a91759d.policy (1)

1-6: LGTM!

The policy correctly grants write access to SecretDocument resources only to principals in the security-admin role. The syntax and logic are sound.

tarpDemo/6e46e36071466cc37c0e9bbd65f16c51ea2ab152c6fc.policy (1)

1-6: LGTM!

The policy correctly permits any Jans::User entity to perform the Search action on Application resources. The syntax is valid Cedar.

tarpDemo/50c0ea31a9ed25a575b7538dec38cb953431651e7bec.policy (1)

1-10: LGTM!

The policy demonstrates proper attribute-based access control with Cedar. The when clause correctly guards against missing attributes by checking principal has email before accessing principal.email.domain.

tarpDemo/13b34711a196f382ade96677cefd513a2a6deff1b949.policy (1)

1-6: LGTM!

The policy correctly grants write access to Application resources for principals in the admin role. Syntax and logic are correct.

449805c83e13f332b1b35eac6ffa93187fbd1c648085.json (2)

7-102: Policy registry looks consistent with policy files.

The policy entries correctly register all new policies with appropriate descriptions. The base64-encoded policy_content fields match the corresponding .policy files in the tarpDemo/ directory.

---

152-157: Verify tx_token configuration completeness.

The tx_token configuration is missing several fields that are present in other token types: required_claims, role_mapping, claim_mapping, and principal_mapping. If transaction tokens will be used for authorization decisions, this incomplete configuration may cause runtime issues.

Is this intentional, or should tx_token have the same metadata fields as the other token types?

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider adding a description for the trusted issuer.

The description field is empty. Adding a brief description would improve documentation and help maintainers understand the purpose of this issuer configuration.

🤖 Prompt for AI Agents

In 449805c83e13f332b1b35eac6ffa93187fbd1c648085.json around lines 105–108 the
trusted issuer entry with id "1985d6d8767b87d752035c9f9c0078daf057ad2cd5ea" has
an empty "description" field; add a concise, one-sentence description that
explains the issuer's purpose (e.g., environment, owner, or service it
represents) so maintainers understand why this issuer exists and any special
context.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Schema is base64-encoded; consider storing human-readable version.

The Cedar schema is stored as a base64-encoded blob, making it difficult to review changes and maintain. Consider storing a human-readable .cedarschema file alongside the JSON configuration for easier review and version control of schema changes.

🤖 Prompt for AI Agents

In 449805c83e13f332b1b35eac6ffa93187fbd1c648085.json around line 161 the
"schema" value is a base64-encoded Cedar schema which hinders reviews; decode
the base64 into a human-readable .cedarschema file committed alongside this
JSON, replace the long base64 blob in the JSON with either a short filename
reference (or the plain JSON-schema text) and update any load/serialization
logic or CI/build scripts to re-encode the file where necessary (add an
encode/decode step in CI or a small helper script) so repository stores a
readable schema while runtime still receives the original encoded form.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Add newline at end of file.

🤖 Prompt for AI Agents

In tarpDemo/28e83add6e203af0d3814f06228e45a0eeb5c1269b08.policy around lines 1
to 9, the file is missing a trailing newline; update the file to end with a
single newline character (ensure the last line breaks with \n) and save so the
file conforms to POSIX newline conventions.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Security issue: Substring matching with .contains() will incorrectly block users from allowed countries.

The condition context.geolocation.contains("restricted") uses substring matching, which will incorrectly trigger for:

• ✅ "restricted" (intended)
• ❌ "unrestricted" (will incorrectly block users from allowed countries)
• ❌ "not_restricted" (will incorrectly block)
• ❌ "restricted_access_allowed" (may incorrectly block)

This could deny legitimate access to users operating from permitted locations.

🔎 Recommended fix using exact equality check

 ) when {
   context has geolocation &&
-  context.geolocation.contains("restricted")
+  context.geolocation == "restricted"
 };

If geolocation contains country codes or a list of restricted locations, use:

 ) when {
   context has geolocation &&
-  context.geolocation.contains("restricted")
+  ["CN", "IR", "KP", "SY"].contains(context.geolocation)
 };

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	context has geolocation &&
	context.geolocation.contains("restricted")
	context has geolocation &&
	context.geolocation == "restricted"

Suggested change

	context has geolocation &&
	context.geolocation.contains("restricted")
	context has geolocation &&
	["CN", "IR", "KP", "SY"].contains(context.geolocation)

🤖 Prompt for AI Agents

In tarpDemo/28e83add6e203af0d3814f06228e45a0eeb5c1269b08.policy around lines
7-8, the rule uses substring matching with
context.geolocation.contains("restricted") which will falsely match values like
"unrestricted" or "restricted_access_allowed"; replace the substring check with
an exact membership test: if geolocation is a single value compare for equality
to the exact restricted token, or if it can be a list/CSV parse it into an array
and test membership (e.g., split/trim then check includes) or use a
full-word/anchored match; ensure the comparison is case-normalized if needed and
update the policy to only block when a precise restricted entry is present.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Policy logic is correct.

The condition properly uses exact equality (context.network_type == "public") to restrict execution on public networks. This is the correct approach for string matching in security contexts.

Add newline at EOF

The file should end with a newline character for POSIX compliance.

🤖 Prompt for AI Agents

In tarpDemo/420184da127304d1b2898761893a974096f6dbade45a.policy around lines 1
to 9, the file is missing a trailing newline at EOF; add a single newline
character at the end of the file so it ends with a newline (POSIX-compliant) and
save the file.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Policy logic is correct.

The unconditional forbid rule clearly restricts Jans::User principals from writing to SecretDocument resources. However, ensure a newline is added at the end of the file.

🔎 Add newline at EOF

The file should end with a newline character for POSIX compliance.

🤖 Prompt for AI Agents

In tarpDemo/870eaec25d9c8e9a642c4ed4d08b1ad480e6bc1348c7.policy around lines 1
to 6, the policy is correct but the file is missing a trailing newline; add a
single newline character at the end of the file (ensure the file ends with '\n')
so it conforms to POSIX/EOF conventions.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Policy logic is correct.

The unconditional permit rule appropriately grants Jans::User principals the ability to monitor Jans::Application resources.

Add newline at EOF

The file should end with a newline character for POSIX compliance.

🤖 Prompt for AI Agents

In tarpDemo/b5111ecf0d218da2cdbece83aeb77cb6b479d3b5d85c.policy around lines 1
to 6, the policy is correct but the file is missing a trailing newline; to fix,
open the file and add a single newline character at the end of the file (ensure
the file ends with '\n') then save so it complies with POSIX EOF conventions.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Policy logic is correct.

The unconditional permit rule appropriately grants Jans::User principals the ability to execute Jans::Application resources.

Add newline at EOF

The file should end with a newline character.

🤖 Prompt for AI Agents

In tarpDemo/e76eb1853f0c6a199ca383cd9714e0113dfd851e079a.policy around lines
1-6, the file is missing a trailing newline at EOF; simply add a single newline
character at the end of the file so it ends with a newline (ensure there is
exactly one newline and no extra whitespace after it).

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Add newline at end of file.

Cedar policy files should end with a newline character for POSIX compliance and better version control diffs.

🤖 Prompt for AI Agents

In tarpDemo/f38f10e80c6f429153cf97781a4c6bcf29761a04259f.policy around lines
1-9, the file is missing a trailing newline; update the file to ensure it ends
with a single newline character (POSIX EOF newline) so the file terminates with
'\n' and save/commit the change.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Security issue: Substring matching with .contains() is unsafe for role validation.

The condition !principal.role.contains("admin") will match any string containing "admin" as a substring, including:

• ✅ "admin" (intended)
• ⚠️ "administrator" (likely unintended)
• ⚠️ "not_admin" (unintended - would be blocked despite not being admin)
• ⚠️ "domain_admin_user" (unintended)

This creates a security risk where users with roles like "not_admin" would be incorrectly denied access, and users with "administrator" might be incorrectly granted access (depending on intent).

🔎 Recommended fix using exact equality check

 ) when {
   principal has role &&
-  !principal.role.contains("admin")
+  principal.role != "admin"
 };

If role is a set/list of roles, use:

 ) when {
   principal has role &&
-  !principal.role.contains("admin")
+  !(principal.role.contains("admin"))
 };

But ensure the role value is exactly "admin", not a partial match. Consider using a dedicated admin role attribute or exact string equality.

🤖 Prompt for AI Agents

In tarpDemo/f38f10e80c6f429153cf97781a4c6bcf29761a04259f.policy around lines 7-8
the condition uses substring matching (!principal.role.contains("admin")) which
produces false positives/negatives; change it to an exact role check: if role is
a single string use equality (principal.role == "admin"), if role is a
collection check membership (!("admin" in principal.role) or
principal.role.containsExact("admin") depending on policy language), and also
normalize/trim the value (case/whitespace) if needed to avoid accidental
mismatches.