OIDC walkthrough and link-checker fixes

docs-main/appdev/app-rewards.mdx

@@ -37,7 +37,7 @@ The flow:
 
 ## Getting Featured
 
-After [CIP-0078](https://github.com/hyperledger-labs/splice/blob/main/cips/0078-featured-apps.md), only **featured applications** are eligible for app rewards. An unfeatured application's activity markers will not be converted into reward coupons.
+After [CIP-0078](https://github.com/canton-foundation/cips/blob/main/cip-0078/cip-0078.md), only **featured applications** are eligible for app rewards. An unfeatured application's activity markers will not be converted into reward coupons.
 
 To get your application featured:
 

docs-main/appdev/modules/m4-canton-coin.mdx

@@ -7,7 +7,7 @@ Every transaction on the Global Synchronizer costs traffic. Canton Coin (CC) is
 
 ## Canton Coin
 
-Canton Coin is the native utility token of the Global Synchronizer. It is implemented through [Splice](https://github.com/hyperledger-labs/splice), the open-source infrastructure layer for decentralized Canton synchronizers.
+Canton Coin is the native utility token of the Global Synchronizer. It is implemented through [Splice](https://github.com/canton-network/splice), the open-source infrastructure layer for decentralized Canton synchronizers.
 
 CC has several primary purposes on the network:
 

docs-main/appdev/quickstart/lnav.mdx

@@ -43,7 +43,7 @@ The Canton Network has a custom `lnav` configuration to help you view and analyz
 
 Download the configuration and install it for `lnav` usage:
 
-    curl -L https://raw.githubusercontent.com/hyperledger-labs/splice/main/canton/canton-json.lnav.json -o /tmp/canton-json.lnav.json && lnav -i /tmp/canton-json.lnav.json
+    curl -L https://raw.githubusercontent.com/canton-network/splice/main/canton/canton-json.lnav.json -o /tmp/canton-json.lnav.json && lnav -i /tmp/canton-json.lnav.json
 
 Now you're ready to navigate CN logs with `lnav`.
 

docs-main/docs.json

@@ -2571,6 +2571,7 @@
                   "global-synchronizer/production-operations/decommission-nodes",
                   "global-synchronizer/production-operations/node-backup-restore",
                   "global-synchronizer/deployment/identity-management",
+                  "global-synchronizer/deployment/oidc-providers",
                   "global-synchronizer/deployment/docker",
                   "global-synchronizer/reference/metrics-reference",
                   "global-synchronizer/troubleshooting-guide/runbooks",
@@ -2724,6 +2725,7 @@
                   "global-synchronizer/production-operations/decommission-nodes",
                   "global-synchronizer/production-operations/node-backup-restore",
                   "global-synchronizer/deployment/identity-management",
+                  "global-synchronizer/deployment/oidc-providers",
                   "global-synchronizer/deployment/docker",
                   "global-synchronizer/reference/metrics-reference",
                   "global-synchronizer/troubleshooting-guide/runbooks",
@@ -2877,6 +2879,7 @@
                   "global-synchronizer/production-operations/decommission-nodes",
                   "global-synchronizer/production-operations/node-backup-restore",
                   "global-synchronizer/deployment/identity-management",
+                  "global-synchronizer/deployment/oidc-providers",
                   "global-synchronizer/deployment/docker",
                   "global-synchronizer/reference/metrics-reference",
                   "global-synchronizer/troubleshooting-guide/runbooks",

docs-main/global-synchronizer/deployment/configuration.mdx

@@ -34,9 +34,9 @@ Example env: ADDITIONAL_CONFIG_EXAMPLE="canton.example.key=value"
 
 The full configuration for each app can be observed in the scala code, with the configuration key being kebab case compared to the camel case in the scala code:
 
-- [ValidatorAppConfig.scala](https://github.com/hyperledger-labs/splice/blob/main/apps/validator/src/main/scala/org/lfdecentralizedtrust/splice/validator/config/ValidatorAppConfig.scala#L141)
-- [SvAppConfig.scala](https://github.com/hyperledger-labs/splice/blob/main/apps/sv/src/main/scala/org/lfdecentralizedtrust/splice/sv/config/SvAppConfig.scala#L199)
-- [ScanAppConfig.scala](https://github.com/hyperledger-labs/splice/blob/main/apps/scan/src/main/scala/org/lfdecentralizedtrust/splice/scan/config/ScanAppConfig.scala#L28)
+- [ValidatorAppConfig.scala](https://github.com/canton-network/splice/blob/main/apps/validator/src/main/scala/org/lfdecentralizedtrust/splice/validator/config/ValidatorAppConfig.scala#L141)
+- [SvAppConfig.scala](https://github.com/canton-network/splice/blob/main/apps/sv/src/main/scala/org/lfdecentralizedtrust/splice/sv/config/SvAppConfig.scala#L199)
+- [ScanAppConfig.scala](https://github.com/canton-network/splice/blob/main/apps/scan/src/main/scala/org/lfdecentralizedtrust/splice/scan/config/ScanAppConfig.scala#L28)
 
 Furthermore, the participant and other synchronizer components can be configured independently as well. Further info on such configurations can be found in the [daml docs](https://docs.daml.com/canton/usermanual/static_conf.html).
 

docs-main/global-synchronizer/deployment/oidc-providers.mdx

@@ -0,0 +1,148 @@
+---
+title: "Okta and Keycloak OIDC Configuration Guide"
+description: "Step-by-step OIDC provider setup walkthroughs for Okta and Keycloak when deploying a Canton Network validator node."
+---
+
+{/* COPIED_START source="splice:docs/src/community/oidc-config-okta-keycloak.rst" hash="bb49ca0b" */}
+
+<Warning title="Pre-reviewed Content - Do Not Modify">
+This section was copied from existing reviewed documentation.
+**Source:** `docs/src/community/oidc-config-okta-keycloak.rst`
+Reviewers: Skip this section. Remove markers after final approval.
+</Warning>
+
+<Warning>
+This section features solutions shared by community members.
+While they haven't been formally tested by the Splice maintainers,
+users are encouraged to verify the information independently.
+Contributions to enhance accuracy and completeness are always welcome.
+</Warning>
+
+To deploy a validator node, configure authentication using your preferred OIDC provider.
+This section provides instructions for Okta and Keycloak.
+For Auth0 instructions and more details on configuring authentication, see [Configuring Authentication](/global-synchronizer/deployment/installation#configuring-authentication).
+
+Thanks to Stéphane Loeuillet for contributing input in a [community discussion](https://github.com/global-synchronizer-foundation/docs/discussions/15#discussioncomment-12877002), which forms the basis of the Okta section in this document.
+
+## Okta
+
+Follow these steps to configure Okta as your validator's OIDC provider:
+
+1. Create an application for the validator app backend.
+
+   a. Navigate to "Admin Panel > Applications > Applications", and click "Create App Integration".
+   b. Choose "API Services" as the sign-in method (not OIDC).
+   c. For "App integration name", enter `Validator app backend`.
+   d. In General Settings, uncheck "Proof of possession".
+   e. Click "Save" and copy the "Client ID" and "Client Secret".
+
+2. Create an application for the wallet web UI.
+
+   a. Navigate to "Admin Panel > Applications > Applications", and click "Create App Integration".
+   b. Choose "OIDC" as the sign-in method then "Single-Page Application" as the application type.
+   c. For "App integration name", enter `Wallet web UI`.
+
+      - In "Sign-in redirect URIs", enter your wallet UI URL: `https://wallet.validator.YOUR_HOSTNAME`
+      - In "Sign-out redirect URIs", enter your wallet UI URL: `https://wallet.validator.YOUR_HOSTNAME`
+      - In "Trusted Origins/Base URIs", enter your wallet UI URL: `https://wallet.validator.YOUR_HOSTNAME`
+
+   d. Assign the app to the groups you want to have access to it.
+   e. Click "Save" and copy the "Client ID".
+
+3. Create an application for the CNS web UI.
+
+   a. Navigate to "Admin Panel > Applications > Applications", and click "Create App Integration".
+   b. Choose "OIDC" as the sign-in method then "Single-Page Application" as the application type.
+   c. For "App integration name", enter `CNS web UI`.
+
+      - In "Sign-in redirect URIs", enter your CNS UI URL : `https://cns.validator.YOUR_HOSTNAME`
+      - In "Sign-out redirect URIs", enter your CNS UI URL : `https://cns.validator.YOUR_HOSTNAME`
+      - In "Trusted Origins/Base URIs", enter your CNS UI URL : `https://cns.validator.YOUR_HOSTNAME`
+
+   d. Assign the app to the groups you want to have access to it.
+   e. Click "Save" and copy the "Client ID".
+
+4. Create a client for a custom audience (optional)
+
+   a. If you want other applications to access the ledger API, create an additional client by following steps 1–3.
+
+5. Create a custom Authorization server per validator/environment
+
+   a. Navigate to "Admin Panel > Directory > Groups", click "Add Group" and name the group "canton_wallet_admin".
+   b. Add another group "canton_all."
+   c. Navigate to "Admin Panel > Security > API"
+   d. In the "Authorization Servers" tab, click "Add Authorization Server". Define a name and audience. Note that the authorization server is used for the M2M flow and must be different for each environment/validator for security reasons.
+   e. In the "Scopes" tab, add a custom scope named `daml_ledger_api`  and click "Set as a default scope".
+   f. In the "Claims" tab, change the "sub" value to "app.clientId". If the default value is kept, it uses the user email, which requires formatting in values.yaml as `' " email.address@domain " '`, without the spaces. This is necessary until the Helm chart is updated to properly quote them.
+   g. In the "Access Policies" tab, create one policy for each of the three applications.
+
+      - Name: `Validator app backend`
+      - Assigned to : `Validator app backend` created in step #1
+      - Click "Add rule." Enter a "Rule Name" and check "Any user assigned the app" next to "User is" to define a rule that matches any user assigned to the app. Click "Create rule."
+
+      - Name: `Wallet web UI`
+      - Assigned to: `Wallet web UI` created in step #2
+      - Click "Add rule." Enter a "Rule Name" and check "Assigned the app and a member of one of the following" next to "User is." Add the group "canton_wallet_admin" to define a rule that matches the group. Click "Create rule."
+
+      - Name: `CNS web UI`
+      - Assigned to: `CNS web UI` created in step #3
+      - Click "Add rule." Enter a "Rule Name" and check "Assigned the app and a member of one of the following" next to "User is." Add the group "canton_all" to define a rule that matches the group. Click "Create rule."
+
+## Keycloak
+
+Follow these steps to configure Keycloak as your validator's OIDC provider:
+
+1. Create a realm
+
+   a. Navigate to "Admin Panel > Manage realms", click "Create realm", and enter a realm name.
+
+2. Create a client for the Ledger API
+
+   a. Navigate to "Admin Panel > Clients" and click "Create client".
+   b. Set the client type to "OpenID Connect", enter `ledger-api` as the client ID, and click "Next".
+   c. In the "Capability config", uncheck all fields and click "Next".
+   d. In the "Login settings", leave the "Valid redirect URIs" and "Web origins" fields blank, then click "Save".
+   e. Navigate to the "Admin Panel > Client scopes" tab and click "Create client scope".
+   f. Enter `daml_ledger_api` as the name and select the type "Default".
+   g. In the "Mappers" tab, click "Configure a new mapper".
+   h. Select "User Client Role" as the mapper type and name it `daml_ledger_api_scope`. Enable "Add to Access Token" and disable all the other options, such as "Add to ID token", "Add to userinfo", and "Add to token introspection". Click "Save".
+   i. To add this scope to the `ledger-api` client, navigate to "Admin Panel > Clients > ledger_api > Client scopes" and click "Add client scope". Select `daml_ledger_api` and click "Add" with the type "Default".
+   j. Navigate to "Admin Panel > Realm Settings > Sessions", and ensure that "Offline Session Max Limited" is enabled with a sufficient value for "Offline Session Max." This enables refresh tokens, similar to "Allow Offline Access" in Auth0. Click "Save".
+
+3. Create a client for a custom audience (optional)
+
+   a. If your backend services require a different audience, create another client with the "Client ID" set to `validator-app-api` (e.g., `https://validator.example.com/api`), and optionally define custom client scopes as described in step #2 to distinguish this API.
+
+4. Create a client for the validator app backend.
+
+   a. Navigate to "Admin Panel > Clients" and click "Create client".
+   b. Set the client type to "OpenID Connect", enter `validator-app-backend` as the client ID, and click "Next".
+   c. In the "Capability config", only check "Client authentication" and "Service accounts". Click "Next".
+   d. In the "Login settings", leave the "Valid redirect URIs" and "Web origins" fields blank, then click "Save".
+   e. Copy the "Client ID" from the "Settings" tab and "Client Secret" from the "Credentials" tab. The Client ID in Keycloak is the name assigned to the client at creation (`validator-app-backend`).
+
+5. Create a client for the wallet web UI.
+
+   a. Navigate to "Admin Panel > Clients" and click "Create client".
+   b. Set the client type to "OpenID Connect", enter `wallet-web-ui` as the client ID, and click "Next".
+   c. In the "Capability config", only check "Standard flow" and click "Next".
+   d. In the "Login settings", set:
+
+      - "Valid redirect URIs" to: `https://wallet.validator.YOUR_HOSTNAME/*`
+      - "Valid post logout redirect URIs" to: `https://wallet.validator.YOUR_HOSTNAME`
+      - "Web origins" to: `https://wallet.validator.YOUR_HOSTNAME`
+      - Click Save.
+
+   e. Copy the "Client ID" from the "Settings" tab (`wallet-web-ui`).
+
+6. Create a client for the CNS web UI.
+
+   a. Follow the same steps as for the wallet web UI, using `cns-ui` as the "Client ID", setting:
+
+      - "Valid redirect URIs" to: `https://cns.validator.YOUR_HOSTNAME/*`
+      - "Valid post logout redirect URIs" to: `https://cns.validator.YOUR_HOSTNAME`
+      - "Web origins" to: `https://cns.validator.YOUR_HOSTNAME`
+
+   b. Copy the "Client ID" from the "Settings" tab (`cns-ui`).
+
+{/* COPIED_END */}

docs-main/global-synchronizer/production-operations/logging.mdx

@@ -26,7 +26,7 @@ The default log level, initially set to Debug, can be changed using the `--log-l
 
 **When the node is launched in a kubernetes cluster**, we recommend to setup a log collector so that you can capture logs of at least the last day. For now, the default log level is set to Debug.
 
-We recommend to use `lnav` to read the logs. A guideline is provided in [this documentation](https://github.com/hyperledger-labs/splice/blob/main/TESTING.md#setting-up-lnav-to-inspect-canton-and-cometbft-logs).
+We recommend to use `lnav` to read the logs. A guideline is provided in [this documentation](https://github.com/canton-network/splice/blob/main/TESTING.md#setting-up-lnav-to-inspect-canton-and-cometbft-logs).
 
 <Note>
 Logging in kubernetes (note that this only provides logs for a limited timeframe):

docs-main/global-synchronizer/production-operations/multi-sig.mdx

@@ -184,26 +184,26 @@ can take the actual actions, and under which conditions.
 
 In the case of the Canton Coin app, for example, the `dsoParty` is a
 decentralized party that is the signatory on the [dsoRules
-contract](https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L441)).
+contract](https://github.com/canton-network/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L441)).
 The contract has a list of Super Validators (the `svs`
-[field](https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L444)
+[field](https://github.com/canton-network/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L444)
 in the contract) that participate in the application.
 
 Certain actions can then be taken by any SV, assuming certain conditions
 hold. These conditions are enforced via assertions in the Daml workflows
 themselves. For example, any SV can execute the [DsoRules_Amulet_Expire
-choice](https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L1095C34-L1095C43)
+choice](https://github.com/canton-network/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L1095C34-L1095C43)
 to archive an Amulet contract for which the expiration date has already
 passed.
 
 Other actions require collecting enough confirmations from other SVs.
 This is also implemented in Daml. For example, any SV can invoke the
 [DsoRules_RequestVote
-choice](https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L674C34-L674C43).
+choice](https://github.com/canton-network/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L674C34-L674C43).
 Any SV can then cast a vote on it via invoking the [DsoRules_CastVote
-choice](https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L712).
+choice](https://github.com/canton-network/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L712).
 Any SV can then also invoke the [DsoRules_CloseVoteRequest
-choice](https://github.com/hyperledger-labs/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L761)
+choice](https://github.com/canton-network/splice/blob/0f194d4e5b55722cfd14b82a74e4b0db47f0f251/daml/splice-dso-governance/daml/Splice/DsoRules.daml#L761)
 to complete the process. Under the conditions encoded in Daml (e.g.
 enough "Yay" votes, and a certain time has been reached), the action
 voted on may be taken by the `dsoParty`. Note that all submissions in

docs-main/global-synchronizer/production-operations/security-hardening.mdx

@@ -51,7 +51,7 @@ Refer to the [Canton documentation](https://docs.daml.com/canton/usermanual/kms/
 You can grant the `Cloud KMS Admin` and `Cloud KMS Crypto Operator` roles to the validator KMS service account.
 {/* COPIED_END */}
 
-A mock GCP KMS configuration is available in [apps/app/src/pack/examples/sv-helm/kms-participant-gcp-values.yaml](https://github.com/hyperledger-labs/splice/blob/main/apps/app/src/pack/examples/sv-helm/kms-participant-gcp-values.yaml).
+A mock GCP KMS configuration is available in [apps/app/src/pack/examples/sv-helm/kms-participant-gcp-values.yaml](https://github.com/canton-network/splice/blob/main/apps/app/src/pack/examples/sv-helm/kms-participant-gcp-values.yaml).
 
 ### Amazon Web Services KMS
 
@@ -66,7 +66,7 @@ Refer to the [Canton documentation](https://docs.daml.com/canton/usermanual/kms/
 - `kms:GetPublicKey`
 {/* COPIED_END */}
 
-A mock AWS KMS configuration is available in [apps/app/src/pack/examples/sv-helm/kms-participant-aws-values.yaml](https://github.com/hyperledger-labs/splice/blob/main/apps/app/src/pack/examples/sv-helm/kms-participant-aws-values.yaml).
+A mock AWS KMS configuration is available in [apps/app/src/pack/examples/sv-helm/kms-participant-aws-values.yaml](https://github.com/canton-network/splice/blob/main/apps/app/src/pack/examples/sv-helm/kms-participant-aws-values.yaml).
 
 ### Migrating from software keys to KMS