Merge branch 'main' into cn-grpc-bridge

Author: iromli

.github/workflows/build-docs.yml

@@ -8,6 +8,7 @@ on:
       - 'charts/**'
       - 'mkdocs.yml'
       - 'docker-jans-**/README.md'
+      - 'CHANGELOG.md'
   pull_request:
     branches:
       - main
@@ -16,6 +17,7 @@ on:
       - 'charts/**'
       - 'mkdocs.yml'
       - 'docker-jans-**/README.md'
+      - 'CHANGELOG.md'
   release:
     types:
       - published
@@ -87,6 +89,12 @@ jobs:
           github.event_name == 'workflow_dispatch'
         run: |
           mv ../mkdocs.yml mkdocs.yml
+          cp ../CHANGELOG.md docs/CHANGELOG.md
+
+      - name: Sync CHANGELOG to docs
+        if: github.event_name != 'workflow_dispatch'
+        run: |
+          cp CHANGELOG.md docs/CHANGELOG.md
 
       - name: Copy generated chart from main
         run: |

docs/CHANGELOG.md

@@ -27,7 +27,7 @@ For example, you may have a policy that says *Admins* can *write* to the */confi
 is the Principal, *write* is the Action, and the */config* folder is the Resource. The Context is used to
 specify information about the environment, like the time of day or network address.
 
-![Cedar, Cedarling, and Lock diagram](../assets/lock-cedarling-diagram-3.jpg)
+![Cedar, Cedarling, and Lock diagram](assets/lock-cedarling-diagram-3.jpg)
 
 Fine grain access control makes sense in both the frontend and backend. In the frontend, mastery of
 authz can help developers build better UX. For example, why display form fields a user is not

docs/cedar-intro.md

@@ -90,7 +90,7 @@ Example request to the evaluation endpoint:
 }
 ```
 
-Cedarling requires OpenID Userinfo, Access, and ID tokens to construct the principal entity, as described [here](../../cedarling-authz.md). These values are sent in the subject field's properties. Furthermore, the sidecar expects the SHA256 checksum of the subject and resource's `properties` dictionary to be passed as their corresponding IDs, as shown in the example above. A more detailed example of creating an AuthZen request can be seen in the [gateway example](./cedarling-sidecar-tutorial.md#setup-test-gateway)
+Cedarling requires OpenID Userinfo, Access, and ID tokens to construct the principal entity, as described [here](../../reference/cedarling-authz.md). These values are sent in the subject field's properties. Furthermore, the sidecar expects the SHA256 checksum of the subject and resource's `properties` dictionary to be passed as their corresponding IDs, as shown in the example above. A more detailed example of creating an AuthZen request can be seen in the [gateway example](./cedarling-sidecar-tutorial.md#setup-test-gateway).
 
 Upon creating the principal, action, resource, and context entities, cedarling will evaluate these entities against the policies defined in the policy store. Then it will return a true/false decision. If the decision is false, the sidecar will analyze cedarling diagnostics and provide additional information for the admin.
 

docs/cedarling/developer/sidecar/cedarling-sidecar-overview.md

@@ -21,7 +21,7 @@ grain access controls needed to implement the business rules of their applicatio
 to define schema and policies is to use the [AgamaLab](https://cloud.gluu.org/agama-lab) Policy
 Designer. This is a free developer tool hosted by [Gluu](https://gluu.org).
 
-![](../assets/lock-cedarling-diagram-2.jpg)
+![Diagram showing Cedarling authorization flow with JWTs, Resource, Action, and Context](../../assets/lock-cedarling-diagram-2.jpg)
 
 The JWTs, Resource, Action, and Context are sent in the authz request. Cedar Pricipals entities
 are derived from JWT tokens. The OpenID Connect ("OIDC") JWTs are joined by the Cedarling to create

docs/cedarling/reference/cedarling-authz.md

@@ -174,7 +174,7 @@ This feature is toggled with the `CEDARLING_JWT_STATUS_VALIDATION` property.
 
 JWTs (JSON Web Tokens) contain authorization information that is used by the Cedarling to construct the Principal entities. In order to verify the authenticity of this information, the Cedarling can verify the integrity of the JWT by validating its signature and status(active, expired, or revoked). It does so by fetching the public keyset and the list of active tokens from the issuer of the JWT.
 
-![](../assets/lock-cedarling-diagram-4.jpg)
+![Cedarling JWT validation flow diagram showing token verification process](../../assets/lock-cedarling-diagram-4.jpg)
 
 ## Local JWKS
 

docs/cedarling/reference/cedarling-jwt-validation.md

@@ -46,7 +46,7 @@ After creation, **export the SSA token** and save it securely.
 
 ### 2. Setting up the Interception Script
 
-Next, configure an [*interception script*](../janssen-server/developer/interception-scripts.md) to automatically add the required scopes when a Cedarling client registers.
+Next, configure an [*interception script*](../../janssen-server/developer/scripts/README.md) to automatically add the required scopes when a Cedarling client registers.
 
 In your server, create a script file at `/opt/jans/jetty/jans-auth/custom/script/add_cedarling_scopes.py` with the following content:
 
@@ -170,24 +170,24 @@ Next, create a JSON file named `script_schema.json` with the following content:
   "programmingLanguage": "python",
   "moduleProperties": [],
   "configurationProperties": [
-	{
-		"value1": "jwks_uri",
-		"value2": "https://demoexample.jans.io/jans-auth/restv1/jwks",
-		"hide": false,
-		"description": "JWKS URI used for the SSA validation"
-	},
-	{
-		"value1": "scope_list",
-		"value2": "https://jans.io/oauth/lock/log.write https://jans.io/oauth/lock/health.write https://jans.io/oauth/lock/telemetry.write",
-		"hide": false,
-		"description": "space-separated scopes that will be added by the script"
-	},
-	{
-		"value1": "trigger_scope",
-		"value2": "cedarling",
-		"hide": false,
-		"description": "the scope that must be present for the script to run"
-	}
+        {
+                "value1": "jwks_uri",
+                "value2": "https://demoexample.jans.io/jans-auth/restv1/jwks",
+                "hide": false,
+                "description": "JWKS URI used for the SSA validation"
+        },
+        {
+                "value1": "scope_list",
+                "value2": "https://jans.io/oauth/lock/log.write https://jans.io/oauth/lock/health.write https://jans.io/oauth/lock/telemetry.write",
+                "hide": false,
+                "description": "space-separated scopes that will be added by the script"
+        },
+        {
+                "value1": "trigger_scope",
+                "value2": "cedarling",
+                "hide": false,
+                "description": "the scope that must be present for the script to run"
+        }
   ],
   "level": 100,
   "revision": 0,
@@ -239,7 +239,7 @@ A successful response will contain the following scopes:
 
 > Note:
 >
-> If you want to learn more about configuring the example interception script, see the [reference](../janssen-server/developer/interception-scripts.md).
+> If you want to learn more about configuring the example interception script, see the [reference](../../janssen-server/developer/scripts/README.md).
 
 ---
 

docs/cedarling/reference/cedarling-lock-server.md

@@ -487,7 +487,7 @@ Cedarling currently provides two modes of authorization:
 - Doesn't use principal and all token information is stored in context.
 - This makes authorization decisions by rules based on context values (token payloads).
 
-[More information](./cedarling-multi-issuer.md)
+[More information](../reference/cedarling-multi-issuer.md)
 
 ### Logging
 

docs/cedarling/tutorials/cedarling-getting-started.md

@@ -421,6 +421,6 @@ Auto-generated documentation is available on [pkg.go.dev](https://pkg.go.dev/git
 
 ## See Also
 
-- [Multi-Issuer Authorization Details](../cedarling-authz.md#multi-issuer-authorization-authorize_multi_issuer)
-- [JWT Mapping for Multi-Issuer](../cedarling-jwt-mapping.md#multi-issuer-jwt-mapping-authorize_multi_issuer)
-- [Policy Store Configuration](../cedarling-policy-store.md#multi-issuer-token-entities)
+- [Multi-Issuer Authorization Details](../reference/cedarling-authz.md)
+- [JWT Mapping for Multi-Issuer](../reference/cedarling-jwt-mapping.md)
+- [Policy Store Configuration](../reference/cedarling-policy-store.md)

docs/cedarling/tutorials/go.md

@@ -37,8 +37,8 @@ The Cedarling performs other tasks associated with a Policy Decision Point, or "
 ## Cedarling Flow
 
 ### Startup Requirements
-1. [Bootstrap Properties](../../../cedarling/cedarling-properties.md)
-2. [Policy Store](../../../cedarling/cedarling-policy-store.md)
+1. [Bootstrap Properties](../../../cedarling/reference/cedarling-properties.md)
+2. [Policy Store](../../../cedarling/reference/cedarling-policy-store.md)
 
 ### Authorization Flow
 
@@ -63,7 +63,7 @@ Handled via `JwtService` in the `jwt` module. JWTs from untrusted issuers are re
 
 Criteria for valid JWT:
     * Comes from a trusted issuer:
-    * Has a defined [token metadata](../../../cedarling/cedarling-policy-store.md#token-metadata-schema)
+    * Has a defined [token metadata](../../../cedarling/reference/cedarling-policy-store.md#token-metadata-schema)
 
 
 
@@ -73,7 +73,7 @@ Handled via `EntityBuilder` in the `entity_builder` module. JWTs from untrusted
 
 JWT claims are mapped to Cedar attributes (1:1 by default).
 
-Mappings are configured via the Token Entity Metadata Schema's `claim mapping` field in the [Policy Store](../../../cedarling/cedarling-policy-store.md#claim-mapping).
+Mappings are configured via the Token Entity Metadata Schema's `claim mapping` field in the [Policy Store](../../../cedarling/reference/cedarling-policy-store.md#claim-mapping).
 
 
 !!! Note