nginx · ADubhlaoich · Oct 23, 2025 · Oct 22, 2025 · Oct 23, 2025
@@ -36,5 +36,5 @@ MD039: true
 # All images should have alt text
 MD045: true
 
-# Tables shou ld be surrounded by blank lines
+# Tables should be surrounded by blank lines
 MD058: true
@@ -1,17 +1,17 @@
 ---
-nd-docs: DOCS-000
 title: Submit templates
 toc: true
 weight: 200
-type:
-- how-to
+nd-content-type: how-to
+nd-product: ONE
 ---
 
 # Template submission and preview guide
 
 This guide explains how to submit templates for rendering NGINX configurations and preview the results using the Templates API.
 
 Before submitting templates for preview, you need to import templates into NGINX One Console. 
+
 - See the [Import Templates Guide]({{< ref "import-templates.md" >}}) for instructions on creating templates. 
 - For guidance on writing templates, see the [Template Authoring Guide]({{< ref "author-templates.md" >}}).
 
@@ -20,11 +20,11 @@ Before submitting templates for preview, you need to import templates into NGINX
 Template submission allows you to compose templates that generate complete NGINX configuration. The process involves:
 
 1. **Discovering templates** - Find base and augment templates that match your infrastructure needs
-2. **Understanding capabilities** - Review what contexts and features the base template supports
-3. **Selecting augments** - Choose augments for additional features (CORS, rate limiting, SSL, etc.)
-4. **Providing values** - Supply values for all template variables
-5. **Preview and validate** - Generate and review the complete NGINX configuration
-6. **Save as staged config** - Use NGINX One Console to save the preview as a staged configuration for deployment
+1. **Understanding capabilities** - Review what contexts and features the base template supports
+1. **Selecting augments** - Choose augments for additional features (CORS, rate limiting, SSL, etc.)
+1. **Providing values** - Supply values for all template variables
+1. **Preview and validate** - Generate and review the complete NGINX configuration
+1. **Save as staged config** - Use NGINX One Console to save the preview as a staged configuration for deployment
 
 ## Current limitations
 
@@ -41,7 +41,8 @@ Before creating a submission, find base and augment templates that match your in
 
 Use the [List Templates]({{< ref "/nginx-one/api/api-reference-guide/#operation/listTemplates" >}}) API operation to find templates organized by use case.
 
-**Example Response:**
+**Example response:**
+
 ```json
 {
   "count": 3,
@@ -89,11 +90,13 @@ Use the [List Templates]({{< ref "/nginx-one/api/api-reference-guide/#operation/
 ```
 
 **Use Case Identification:**
+
 - **Base templates** represent primary NGINX use cases (reverse proxy, load balancer, static site, API gateway)
 - **Template descriptions** help identify which base template matches your infrastructure need
 - **augment_includes** shows what additional features each base template supports
 
 **Information Available In API Response:**
+
 - **object_id** - A unique identifier of a template to use in submission requests
 - **type** - Identifies base templates (use exactly one) vs augment templates (use zero or more)
 - **allowed_in_contexts** - Shows where augment templates can be applied within a base template
@@ -106,12 +109,14 @@ The API response contains all information needed for creating a submission to re
 Use the [Retrieve a Template]({{< ref "/nginx-one/api/api-reference-guide/#operation/getTemplate" >}}) API operation only when you need to examine template content or detailed variable requirements.
 
 **When to use template details:**
+
 - Review the actual template code and structure
 - Examine detailed schema definitions for variable validation
 - Understand specific variable names and constraints
 - Debug template behavior or compatibility issues
 
-**Example Response:**
+**Example response:**
+
 ```json
 {
   "allowed_in_contexts": [],
@@ -149,6 +154,7 @@ Use the [Retrieve a Template]({{< ref "/nginx-one/api/api-reference-guide/#opera
 ```
 
 **Details:**
+
 - **Template content** - Shows `augment_includes` placeholders and variable usage (e.g., `{{ .backend_url }}`)
 - **Schema definition** - Shows required variables (`backend_url`) and their validation rules
 - **Variable constraints** - Data types, descriptions, and any pattern requirements
@@ -164,31 +170,41 @@ The following sections describe what you need for the request:
 ### Required parameters
 
 **Query Parameter:**
+
 - `preview_only=true` - Currently the only supported mode. Renders configuration for preview without creating a submission object.
 
 ### Configuration path (`conf_path`)
 
-**Required.** The absolute path where the main NGINX configuration file should be placed.
+{{< call-out "important" >}}
 
-**Examples:**
-- `/etc/nginx/nginx.conf` (standard installation)
-- `/opt/nginx/nginx.conf` (custom installation)
+This path determines where augment configurations are rendered:
 
-**Important:** This path determines where augment configurations are rendered:
 - Base template → renders to the exact `conf_path`
 - Augment templates → render to `{base_dir}/conf.d/augments/{filename}.{hash}.conf`
 
 Where `base_dir` is derived from `conf_path`:
+
 - `conf_path: /etc/nginx/nginx.conf` → augments in `/etc/nginx/conf.d/augments/`
 - `conf_path: /opt/nginx/nginx.conf` → augments in `/opt/nginx/conf.d/augments/`
 
+{{< /call-out >}}
+
+**Required.** The absolute path where the main NGINX configuration file should be placed.
+
+**Examples:**
+
+- `/etc/nginx/nginx.conf` (standard installation)
+- `/opt/nginx/nginx.conf` (custom installation)
+
 ### Template properties
 
 **Base Template:**
+
 - `object_id` - Template unique identifier (use a template where `type` is `base`)
 - `values` - Key-value pairs for template variables
 
 **Augment Templates:**
+
 - `object_id` - Template unique identifier (use a template where `type` is `augment`)
 - `target_context` - NGINX context where the augment should be applied
 - `values` - Key-value pairs for template variables (optional if template has no variables)
@@ -199,13 +215,15 @@ Where `base_dir` is derived from `conf_path`:
 Augment templates must specify a `target_context` that determines where the augment will be placed in the base template.
 
 **Validation:**
+
 - The augment's `target_context` must be listed in the augment template's `allowed_in_contexts` (specified during import)
 
 **Available Contexts:**
 
 See the [Template Authoring Guide]({{< ref "author-templates.md#config-templates-contexts" >}}) for detailed information about context paths and how they map to NGINX configuration structure.
 
 **Rendering Behavior:**
+
 - If the base template has an `augment_includes` placeholder for the target context, the augment content is injected there
 - If the base template doesn't have a matching placeholder, the augment is ignored (no error)
 - If the base template has placeholders but no matching augments are provided, those placeholders render as empty strings
@@ -352,15 +370,18 @@ Parse errors indicate the rendered configuration has NGINX syntax issues, often
 When templates are successfully rendered, the system creates multiple files:
 
 ### Base template output
+
 - **File:** Exact path specified in `conf_path`
 - **Content:** Rendered base template with augment content injected at `augment_includes` points
 
 ### Augment template outputs
+
 - **Location:** `{base_dir}/conf.d/augments/`
 - **Filename:** `{template-name}.{content-hash}.conf`
 - **Content:** Individual augment template rendered output
 
 **Example structure:**
+
 ```
 /etc/nginx/
 ├── nginx.conf                           # Base template output
@@ -417,6 +438,7 @@ Template rendering follows predictable ordering rules at two levels:
 Directives render in the exact order they appear in the template file. This includes the placement of `{{ augment_includes "context_path" . }}` extension points.
 
 **Example:**
+
 ```nginx
 http {
     # This renders first
@@ -435,6 +457,7 @@ http {
 When multiple augments target the same context, they render in the order specified in the submission request's augments array.
 
 **Example submission:**
+
 ```json
 {
   "conf_path": "/etc/nginx/nginx.conf",
@@ -458,6 +481,7 @@ When multiple augments target the same context, they render in the order specifi
 ```
 
 **Rendered output:**
+
 ```text
 http {
     # First augment renders first

@@ -3,7 +3,7 @@ title: "Set up security alerts"
 weight: 500
 toc: true
 nd-content-type: how-to
-nd-product: NGINX One
+nd-product: ONE
 ---
 
 With this page, you'll learn how to set up alerts in F5 Distributed Cloud. Once configured, you'll see the CVEs and insecure configurations associated with your NGINX fleet. These instructions are intended for those responsible for keeping their NGINX infrastructure and application traffic secure. It assumes you know how to:
@@ -139,14 +139,19 @@ When you set up an email alert for a problem, you'll see the alert in:
 
 You may also get a follow-up email with the subject **Alert Resolved**.
 
-> **Important:** Sometimes an **Alert Resolved** email is sent even though the issue is still active.
+{{< call-out "important" >}}
+
+Sometimes an **Alert Resolved** email is sent even though the issue is still active.
 To check the current status, go to the NGINX One Console.
 
 For CVEs, the trusted source is:
+
 - **NGINX One Console > Manage > Instances > `Instance hostname`**
 
 Open the instance dashboard to see the latest list of CVEs. Use the Console, not email, to confirm whether an issue is resolved.
 
+{{< /call-out >}}
+
 ## Summary
 
 In this tutorial, you learned how to:

@@ -1,19 +1,17 @@
 ---
-description: Enable OpenID Connect-based single sign-on (SSO) for applications proxied by NGINX Plus, using Microsoft AD FS as the identity provider (IdP).
-type:
-- how-to
 title: Single Sign-On with Microsoft Active Directory FS
+description: Enable OpenID Connect-based single sign-on (SSO) for applications proxied by NGINX Plus, using Microsoft AD FS as the identity provider (IdP).
 toc: true
 weight: 300
-product: NGINX-PLUS
+nd-content-type: how-to
+nd-product: NPL
 nd-docs: DOCS-1683
 ---
 
 This guide explains how to enable single sign-on (SSO) for applications being proxied by F5 NGINX Plus. The solution uses OpenID Connect as the authentication mechanism, with [Microsoft Active Directory Federation Services](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services) (AD FS) as the Identity Provider (IdP) and NGINX Plus as the Relying Party (RP), or OIDC client application that verifies user identity.
 
 {{< call-out "note" >}} This guide applies to [NGINX Plus Release 35]({{< ref "nginx/releases.md#r35" >}}) and later. In earlier versions, NGINX Plus relied on an [njs-based solution](#legacy-njs-guide), which required NGINX JavaScript files, key-value stores, and advanced OpenID Connect logic. In the latest NGINX Plus version, the new [OpenID Connect module](https://nginx.org/en/docs/http/ngx_http_oidc_module.html) simplifies this process to just a few directives.{{< /call-out >}}
 
-
 ## Prerequisites
 
 - A Microsoft AD FS instance, either on-premises or in [Azure](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/how-to-connect-fed-azure-adfs), with administrator privileges.
@@ -22,7 +20,6 @@ This guide explains how to enable single sign-on (SSO) for applications being pr
 
 - A domain name pointing to your NGINX Plus instance, for example, `demo.example.com`.
 
-
 ## Configure the AD FS Server {#adfs-setup}
 
 [Microsoft Active Directory Federation Services](https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services) (AD FS) serves as the Identity Provider.
@@ -80,15 +77,15 @@ Check the OpenID Connect endpoint URL. By default, AD FS publishes the `.well-kn
    ```shell
    curl https://adfs-server-address/adfs/.well-known/openid-configuration | jq .
    ```
-   where:
+
+   Where:
 
    - the `adfs-server-address` is your AD FS server address
 
    - the `/adfs/.well-known/openid-configuration` is the default address for AD FS for document location
 
    - the `jq` command (optional) is used to format the JSON output for easier reading and requires the [jq](https://jqlang.github.io/jq/) JSON processor to be installed.
 
-
    The configuration metadata is returned in the JSON format:
 
    ```json
@@ -109,23 +106,21 @@ Check the OpenID Connect endpoint URL. By default, AD FS publishes the `.well-kn
 
    `https://adfs-server-address/adfs`.
 
-
 {{< call-out "note" >}} You will need the values of **Client ID**, **Client Secret**, and **Issuer** in the next steps. {{< /call-out >}}
 
-
 ## Set up NGINX Plus {#nginx-plus-setup}
 
 With AD FS configured, you can enable OIDC on NGINX Plus. NGINX Plus serves as the Rely Party (RP) application &mdash; a client service that verifies user identity.
 
-
 1.  Ensure that you are using the latest version of NGINX Plus by running the `nginx -v` command in a terminal:
 
     ```shell
     nginx -v
     ```
+
     The output should match NGINX Plus Release 35 or later:
 
-    ```none
+    ```text
     nginx version: nginx/1.29.0 (nginx-plus-r35)
     ```
 
@@ -142,7 +137,7 @@ With AD FS configured, you can enable OIDC on NGINX Plus. NGINX Plus serves as t
         # ...
     }
     ```
-    <span id="adfs-setup-oidc-provider"></span>
+
 5.  In the [`http {}`](https://nginx.org/en/docs/http/ngx_http_core_module.html#http) context, define the AD FS OIDC provider named `adfs` by specifying the [`oidc_provider {}`](https://nginx.org/en/docs/http/ngx_http_oidc_module.html#oidc_provider) context:
 
     ```nginx
@@ -177,7 +172,7 @@ With AD FS configured, you can enable OIDC on NGINX Plus. NGINX Plus serves as t
 
     - If the **userinfo** directive is set to `on`, NGINX Plus will fetch `/userinfo` from the AD FS and append the claims from userinfo to the `$oidc_claims_` variables.
 
-    - **Important:** All interaction with the IdP is secured exclusively over SSL/TLS, so NGINX must trust the certificate presented by the IdP. By default, this trust is validated against your system's CA bundle (the default CA store for your Linux or FreeBSD distribution). If the IdP's certificate is not included in the system CA bundle, you can explicitly specify a trusted certificate or chain with the [`ssl_trusted_certificate`](https://nginx.org/en/docs/http/ngx_http_oidc_module.html#ssl_trusted_certificate) directive so that NGINX can validate and trust the IdP's certificate.
+    - {{< call-out "important" >}} All interaction with the IdP is secured exclusively over SSL/TLS, so NGINX must trust the certificate presented by the IdP. By default, this trust is validated against your system's CA bundle (the default CA store for your Linux or FreeBSD distribution). If the IdP's certificate is not included in the system CA bundle, you can explicitly specify a trusted certificate or chain with the [`ssl_trusted_certificate`](https://nginx.org/en/docs/http/ngx_http_oidc_module.html#ssl_trusted_certificate) directive so that NGINX can validate and trust the IdP's certificate. {{< /call-out >}}
 
     ```nginx
     http {
@@ -288,7 +283,9 @@ With AD FS configured, you can enable OIDC on NGINX Plus. NGINX Plus serves as t
         }
     }
     ```
+
 12. Save the NGINX configuration file and reload the configuration:
+
     ```nginx
     nginx -s reload
     ```
@@ -368,19 +365,16 @@ http {
 
 4. Refresh `https://demo.example.com/` again. You should be redirected to AD FS for a fresh sign‑in, proving the session has been terminated.
 
-
 ## Legacy njs-based AD FS Solution {#legacy-njs-guide}
 
 If you are running NGINX Plus R33 and earlier or if you still need the njs-based solution, refer to the [Legacy njs-based Microsoft AD FS Guide]({{< ref "nginx/deployment-guides/single-sign-on/oidc-njs/active-directory-federation-services.md" >}}) for details. The solution uses the [`nginx-openid-connect`](https://github.com/nginxinc/nginx-openid-connect) GitHub repository and NGINX JavaScript files.
 
-
 ## See Also
 
 - [NGINX Plus Native OIDC Module Reference documentation](https://nginx.org/en/docs/http/ngx_http_oidc_module.html)
 
 - [Release Notes for NGINX Plus R35]({{< ref "nginx/releases.md#r35" >}})
 
-
 ## Revision History
 
 - Version 2 (August 2025) – Added RP‑initiated logout (logout_uri, post_logout_uri, logout_token_hint) and userinfo support.