zowe · anaxceron · Feb 14, 2024 · Feb 14, 2024 · Feb 14, 2024
diff --git a/docs/extend/extend-apiml/api-mediation-message-service.md b/docs/extend/extend-apiml/api-mediation-message-service.md
@@ -13,7 +13,7 @@ API ML uses a customizable infrastructure to format both REST API error messages
 
 - Message `key` - a unique ID in the form of a dot-delimited string that describes the reason for the message. The `key` enables the UI or the console to show a meaningful and localized message. 
 
-    :::tip**Tips:**
+    :::tip Tips:
     - We recommend using the format `org.zowe.sample.apiservice.{TYPE}.greeting.empty` to define the message key. `{TYPE}` can be the api or log keyword. 
     - Use the message `key` and not the message `number`. The message `number` makes the code less readable, and increases the possibility of errors when renumbering values inside the `number`.
     :::

diff --git a/docs/extend/extend-apiml/api-mediation-oidc-authentication.md b/docs/extend/extend-apiml/api-mediation-oidc-authentication.md
@@ -164,7 +164,7 @@ curl --location 'https://"$HOSTNAME:$PORT"/gateway/api/v1/auth/oidc-token/valida
 An HTTP `200` code is returned if the validation passes. Failure to validate returns an HTTP `40x` error.
 :::
 
-:::note**Azure Entra ID OIDC notes:**
+:::note Azure Entra ID OIDC notes:
 API ML uses the `sub` claim of the ID Token to identify the user, and to map to the mainframe account. Note that the structure of the `sub` claim varies between the Azure token and the OKTA ID token:
 * The Azure token `sub` is an alphanumeric value.  
 For more information, see the topic _Use claims to reliably identify a user_ in the Microsoft Learn documentation.

diff --git a/docs/extend/extend-apiml/custom-metadata.md b/docs/extend/extend-apiml/custom-metadata.md
@@ -6,7 +6,7 @@ Additional metadata can be added to the instance information that is registered
 
     When this parameter is set to `true`, the Gateway allows encoded characters to be part of URL requests redirected through the Gateway. The default setting of `false` is the recommended setting. Change this setting to `true` only if you expect certain encoded characters in your application's requests.
 
-    :::info**Important!**
+    :::info Important
     When the expected encoded character is an encoded slash or backslash (`%2F`, `%5C`), make sure the Gateway is also configured to allow encoded slashes. For  more information, see [Installing the Zowe runtime on z/OS](../../user-guide/install-zos.md).
     :::
 

diff --git a/docs/extend/extend-apiml/onboard-static-definition.md b/docs/extend/extend-apiml/onboard-static-definition.md
@@ -94,7 +94,7 @@ catalogUiTiles:
 
 In this example, a suitable name for the file is `petstore.yml`.
 
-:::note**Notes:**
+:::note Notes:
 
 * The filename does not need to follow specific naming conventions but it requires the `.yml` extension.
 * The file can contain one or more services defined under the `services:` node.
@@ -103,7 +103,7 @@ In this example, a suitable name for the file is `petstore.yml`.
 * One API is provided and the requests with the relative base path `api/v2` at the API Gateway (full gateway URL: `https://gateway:port/serviceId/api/v2/...`) are routed to the relative base path `/v2` at the full URL of the service (`http://localhost:8080/v2/...`).
 * The file on USS should be encoded in ASCII to be read correctly by the API Mediation Layer.
 
-:::tip**Tips:**
+:::tip Tips:
 
 * There are more examples of API definitions at this [link](https://github.com/zowe/api-layer/tree/master/config/local/api-defs).
 * For more details about how to use YAML format, see this [link](https://learnxinyminutes.com/docs/yaml/).
@@ -548,7 +548,7 @@ The `${zoweInstanceDir}` symbol is used in following instructions.
 
     - To place your YAML file within the instance directory, copy your YAML file to the `${zoweInstanceDir}/workspace/api-mediation/api-defs` directory. 
 
-    :::note**Notes:**
+    :::note Notes:
     - The `${zoweInstanceDir}/workspace/api-mediation/api-defs` directory is created the first time that Zowe starts. If you have not yet started Zowe, this directory might be missing.
     - The user ID `ZWESVUSR` that runs the Zowe started task must have permission to read the YAML file.
     :::  

diff --git a/docs/user-guide/address-browser-requirements.md b/docs/user-guide/address-browser-requirements.md
@@ -2,7 +2,7 @@
 
 Review the following browser requirements to avoid browser-specific issues when running particular server-side components.
 
-:::info**Required role:** system programmer
+:::info Required role: system programmer
 :::
 
 ## Zowe Desktop requirements (client PC)

diff --git a/docs/user-guide/address-network-requirements.md b/docs/user-guide/address-network-requirements.md
@@ -3,7 +3,7 @@
 Review the following table during installation of Zowe server-side components to determine which TCP ports are required. 
 Values presented in the table are default values. You can change the values by updating variable values in the `zowe.yaml` file. 
 
-:::info**Required roles:** network administrator, system programmer
+:::info Required roles: network administrator, system programmer
 :::
 
 For more information about variable names in the following table, see the [Zowe YAML configuration file reference](../appendix/zowe-yaml-configuration.md) in the References section.

diff --git a/docs/user-guide/apf-authorize-load-library.md b/docs/user-guide/apf-authorize-load-library.md
@@ -2,7 +2,7 @@
 
 Review this article to learn how to perform APF authorization of Zowe load libraries to make privileged calls. Note that this procedure requires elevated permissions.
 
-:::info**Required role:** security administrator
+:::info Required role: security administrator
 :::
 
 Zowe contains load modules that require access to make privileged z/OS security manager calls. These load modules are held in two load libraries which must be APF authorized. The command `zwe init apfauth` reads the PDS names for the load libraries from `zowe.yaml` and performs the APF authority commands.  

diff --git a/docs/user-guide/api-mediation-sso.md b/docs/user-guide/api-mediation-sso.md
@@ -2,7 +2,7 @@
 
 You can extend Zowe and utilize Zowe Single-Sign-On (SSO) provided by Zowe API Mediation Layer (API ML) to enhance system security and improve the user experience. 
 
-:::info**Required roles:** system administrator, security administrator
+:::info Required roles: system administrator, security administrator
 :::
 
 This article provides an overview of the API ML single-sign-on feature, the principle participants in the SSO process, and links to detailed Zowe SSO documentation. Zowe Single-Sign-On is based on single-user authentication which produces an access token that represents the user in communication with z/OS services accessible through the API Mediation Layer. The access token is issued by the Zowe Authentication and Authorization Service (ZAAS), which is part of API ML. ZAAS issues an access token based on valid z/OS credentials. This token can be validated by any component participating in SSO. 

diff --git a/docs/user-guide/api-mediation-view-service-information-and-api-doc.md b/docs/user-guide/api-mediation-view-service-information-and-api-doc.md
@@ -16,7 +16,7 @@ Services that belong to the same product family are displayed on the same tile.
 2. Click the tile to view header information, the registered services under that family ID,
  and API documentation for that service.
 
-   :::note**Notes:**
+   :::note Notes:
    * The state of the service is indicated in the service tile on the dashboard page.
     If no instances of the service are currently running, the tile displays a message that no services are running.
    * At least one instance of a service must be started and registered with the Discovery Service for it to be visible
@@ -45,7 +45,7 @@ Services that belong to the same product family are displayed on the same tile.
 
    <img src={require("../images/api-mediation/expanded.png").default} alt="endpoint detail" width="500px"/>
 
-   :::note**Notes:**
+   :::note Notes:
    * If a lock icon is visible on the right side of the endpoint panel, the endpoint requires authentication.
    * The structure of the endpoint is displayed relative to the base URL.
    * The URL path of the abbreviated endpoint relative to the base URL is displayed in the following format:

diff --git a/docs/user-guide/api-mediation/api-mediation-jwt-token-refresh.md b/docs/user-guide/api-mediation/api-mediation-jwt-token-refresh.md
@@ -7,7 +7,7 @@ The refresh request requires the token in one of the following formats:
 - A cookie named `apimlAuthenticationToken`.
 - Bearer authentication
 
-:::note**Notes:**
+:::note Notes:
 - The endpoint is disabled by default. For more information, see [Enable JWT token endpoint](configuration-jwt.md#enable-jwt-token-refresh-endpoint).
 - The endpoint is protected by a client certificate.
   For more information, see the OpenAPI documentation of the API Mediation Layer in the API Catalog.

diff --git a/docs/user-guide/api-mediation/authenticating-with-personal-access-token.md b/docs/user-guide/api-mediation/authenticating-with-personal-access-token.md
@@ -1,6 +1,6 @@
 # Authenticating with a Personal Access Token
 
-:::info**Roles:** system programmer, security administrator
+:::info Roles: system programmer, security administrator
 :::
 
 You can use API Mediation Layer to generate, validate, and invalidate a **Personal Access Token (PAT)** that can enable access to tools such as VCS without having to use credentials of a specific person. The use of PAT does not require storing mainframe credentials as part of the automation configuration on a server during application development on z/OS.

diff --git a/docs/user-guide/api-mediation/configuration-access-specific-instance-of-service.md b/docs/user-guide/api-mediation/configuration-access-specific-instance-of-service.md
@@ -1,6 +1,6 @@
 # Retrieving a specific service within your environment 
 
-:::info**Roles:** system programmer, system administrator
+:::info Roles: system programmer, system administrator
 :::
 
 ## Output a routed instance header

diff --git a/docs/user-guide/api-mediation/configuration-at-tls.md b/docs/user-guide/api-mediation/configuration-at-tls.md
@@ -4,7 +4,7 @@ The communication server on z/OS provides a functionality to encrypt HTTP commun
 
 Review this article for descriptions of the configuration parameters required to make the Zowe API Mediation Layer work with AT-TLS, and security recommendations.
 
-:::info**Role:** security administrator
+:::info Role: security administrator
 :::
 
 - [AT-TLS configuration for Zowe](#at-tls-configuration-for-zowe)
@@ -59,13 +59,13 @@ While API ML does not handle TLS on its own with AT-TLS enabled, API ML requires
 
 2. If there is an outbound AT-TLS rule configured for the link between the API Gateway and z/OSMF, set the `zowe.zOSMF.scheme` property to `http`.
 
-:::note**Notes**
+:::note Notes
 * Currently, AT-TLS is not supported in the API Cloud Gateway Mediation Layer component.
 
 * As the Gateway is a core component of API ML, other components that need to interact with the Gateway, such as Zowe ZLUX App Server, also require AT-TLS configuration.
 :::
 
-:::caution**Important security consideration**
+:::caution Important security consideration
 
 Configuring AT-TLS for the Zowe API Mediation Layer requires careful consideration of security settings, specifically as these settings apply to the Client Certificate authentication feature in Zowe API Mediation Layer components, as well as for onboarded services that support the x.509 client certificates authentication scheme.
 

diff --git a/docs/user-guide/api-mediation/configuration-authorization.md b/docs/user-guide/api-mediation/configuration-authorization.md
@@ -1,6 +1,6 @@
 # Configuring authorization for API ML
 
-:::info**Role:** system administrator
+:::info Role: system administrator
 :::
 
 In Zowe's API Mediation Layer, system administrators can limit access to services and information in the API Catalog by hiding sensitive data like service instance URLs, configurable via the apiml.catalog.hide.serviceInfo property in zowe.yaml. Additionally, SAF resource checking for user authorization on specific endpoints is facilitated through various providers, such as Endpoint, Native, and Dummy. These configurations, modifiable in the zowe.yaml file, enhance security by controlling service exposure and ensuring proper authorization checks within the Zowe ecosystem.

diff --git a/docs/user-guide/api-mediation/configuration-client-certificates.md b/docs/user-guide/api-mediation/configuration-client-certificates.md
@@ -1,7 +1,7 @@
 # Enabling single sign on for clients via client certificate configuration
 
 
-:::info**Roles:** system programmer, system administrator, security administrator
+:::info Roles: system programmer, system administrator, security administrator
 :::
 
 Use the following procedure to enable the zowe.yaml file to use a client certificate as the method of authentication for the API Mediation Layer Gateway. 

diff --git a/docs/user-guide/api-mediation/configuration-connection-limits.md b/docs/user-guide/api-mediation/configuration-connection-limits.md
@@ -1,6 +1,6 @@
 # Customizing connection limits
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 By default, the API Gateway accepts up to 100 concurrent connections per route, and 1000 total concurrent connections. Any further concurrent requests are queued until the completion of an existing request. The API Gateway is built on top of Apache HTTP components that require these two connection limits for concurrent requests. 

diff --git a/docs/user-guide/api-mediation/configuration-cors.md b/docs/user-guide/api-mediation/configuration-cors.md
@@ -1,6 +1,6 @@
 # Customizing Cross-Origin Resource Sharing (CORS) 
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 As a system programmer, you can enable the Gateway to terminate CORS requests for itself and also for routed services. By default, Cross-Origin Resource Sharing (CORS) handling is disabled for Gateway routes `gateway/api/v1/**` and for individual services. After enabling the feature as stated in the following procedure, API Gateway endpoints start handling CORS requests. Individual services can control whether they want the Gateway to handle CORS for them through the [Custom Metadata](../../extend/extend-apiml/onboard-spring-boot-enabler/#custom-metadata) parameters.

diff --git a/...uide/api-mediation/configuration-customizing-management-of-apiml-load-limits.md b/...uide/api-mediation/configuration-customizing-management-of-apiml-load-limits.md
@@ -1,6 +1,6 @@
 # Customizing management of API ML load limits 
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 ::: 
 
 As a system programmer, you can customize your configuration for how API ML manages both northbound and southbound load limits in single instances:

diff --git a/docs/user-guide/api-mediation/configuration-customizing-the-api-catalog-ui.md b/docs/user-guide/api-mediation/configuration-customizing-the-api-catalog-ui.md
@@ -1,6 +1,6 @@
 # Customizing the API Catalog UI
 
-:::info**Role:** system administrator
+:::info Role: system administrator
 :::
 
 As a system administrator, you can customize the API Catalog UI to have a similar interface to your organization's service, or with your existing visualization portal.
@@ -71,7 +71,7 @@ An alternative to the API Catalog is displayed
 - **metrics-dashboard**  
  A possible dashboard that could appear in place of the API Catalog 
 
-:::note**Notes:**
+:::note Notes:
 - If the application contains the `homePageUrl` and `statusPageRelativeUrl`, then the full set of information is displayed.
 - If the application contains the `homePageUrl` the link is displayed without the `UP` information.
 - If the application contains the `statusPageRelativeUrl` then `UP` or `DOWN` is displayed based on the `statusPage` without the link.

diff --git a/docs/user-guide/api-mediation/configuration-distributed-load-balancer-cache.md b/docs/user-guide/api-mediation/configuration-distributed-load-balancer-cache.md
@@ -1,6 +1,6 @@
 # Distributing the load balancer cache
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 You can choose to distribute the load balancer cache between instances of the API Gateway. To distribute the load balancer cache, it is necessary that the caching service is running. Gateway service instances are reuqired to have the same DN (Distinguished name) on the server certificate. This may be relevant for the HA setups.

diff --git a/docs/user-guide/api-mediation/configuration-enable-single-sign-on-extenders.md b/docs/user-guide/api-mediation/configuration-enable-single-sign-on-extenders.md
@@ -1,6 +1,6 @@
 # Enabling single sign on for extending services
 
-:::info**Roles:** system programmer, API service extender
+:::info Roles: system programmer, API service extender
 :::
 
 Enabling Single Sign On (SSO) in Zowe involves configuring JWT tokens or PassTickets for secure authentication. The JWT token configuration requires setting up a custom HTTP header to store the token, thereby enhancing secure communication with southbound services. 

diff --git a/docs/user-guide/api-mediation/configuration-extender-jwt.md b/docs/user-guide/api-mediation/configuration-extender-jwt.md
@@ -1,6 +1,6 @@
 # Enabling single sign on for extending services via JWT token configuration 
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 ## Adding a custom HTTP Auth header to store Zowe JWT token

diff --git a/docs/user-guide/api-mediation/configuration-extender-passtickets.md b/docs/user-guide/api-mediation/configuration-extender-passtickets.md
@@ -2,7 +2,7 @@
 
 As a system programmer, follow the procedures described in this article to configure Zowe to use PassTickets, and to enable Zowe to use PassTickets to authenticate towards specific extending services.
 
-:::info**Roles:** system programmer, security administrator
+:::info Roles: system programmer, security administrator
 :::
 
 ## Configuring Zowe to use PassTickets

diff --git a/docs/user-guide/api-mediation/configuration-gateway-retry-policy.md b/docs/user-guide/api-mediation/configuration-gateway-retry-policy.md
@@ -2,7 +2,7 @@
 
 Use the following procedure to change the Gateway retry policy.
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 All requests are disabled as the default configuration for retry with one exception: the server retries `GET` requests that finish with status code `503`.

diff --git a/docs/user-guide/api-mediation/configuration-gateway-timeouts.md b/docs/user-guide/api-mediation/configuration-gateway-timeouts.md
@@ -1,6 +1,6 @@
 # Customizing Gateway timeouts
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 Use the following procedure to change the global timeout value for the API Mediation Layer instance.

diff --git a/docs/user-guide/api-mediation/configuration-jwt.md b/docs/user-guide/api-mediation/configuration-jwt.md
@@ -1,6 +1,6 @@
 # Enabling single sign on for clients via JWT token configuration 
 
-:::info**Roles:** system programmer, system administrator, security administrator
+:::info Roles: system programmer, system administrator, security administrator
 :::
 
 As a system programmer, you can customize how JWT authentication is performed, the service that provides the JWT authentication token, whether it's possible to refresh JWT token and other characteristics of JWT for consumption. 

diff --git a/...i-mediation/configuration-limiting-access-to-info-or-services-in-api-catalog.md b/...i-mediation/configuration-limiting-access-to-info-or-services-in-api-catalog.md
@@ -1,6 +1,6 @@
 # Limiting access to information or services in the API Catalog
 
-:::info**Role:** system administrator
+:::info Role: system administrator
 :::
 
 As a system administrator, you can limit access to information and/or services available within the API Catalog and through the API Mediation Layer and check for the authorization of the user on certain endpoints.

diff --git a/docs/user-guide/api-mediation/configuration-personal-access-token.md b/docs/user-guide/api-mediation/configuration-personal-access-token.md
@@ -1,7 +1,7 @@
 # Enabling single sign on for clients via personal access token configuration 
 
 
-:::info**Roles:** system programmer, system administrator, security administrator
+:::info Roles: system programmer, system administrator, security administrator
 :::
 
 By default the API Mediation Layer does not provide the ability to use personal access tokens. For more information about about

diff --git a/docs/user-guide/api-mediation/configuration-routing.md b/docs/user-guide/api-mediation/configuration-routing.md
@@ -1,6 +1,6 @@
 # Customizing routing behavior 
 
-:::info**Roles:** system programmer, system administrator, security administrator
+:::info Roles: system programmer, system administrator, security administrator
 :::
 
 The Zowe API Mediation Layer offers a range of routing configurations for enhanced functionality and security. 

diff --git a/docs/user-guide/api-mediation/configuration-saf-resource-checking.md b/docs/user-guide/api-mediation/configuration-saf-resource-checking.md
@@ -1,6 +1,6 @@
 # Configuring SAF resource checking 
 
-:::info**Roles:** system programmer, system administrator, security administrator
+:::info Roles: system programmer, system administrator, security administrator
 :::
 You can use various SAF resource providers depending on your use case to handle the SAF authorization check. Follow the procedure in this article that applies to your specific configuration use case. 
 
@@ -95,7 +95,7 @@ The following YAML presents the structure of the file:
         - {UserID}
 ```
 
-:::note**Notes**
+:::note Notes
 - Classes and resources are mapped into a map, user IDs into a list.
 - The load method does not support formatting with dots, such as shown in the following example:
   **Example:** `{CLASS}.{RESOURCE}`

diff --git a/docs/user-guide/api-mediation/configuration-set-consistent-service-id.md b/docs/user-guide/api-mediation/configuration-set-consistent-service-id.md
@@ -1,6 +1,6 @@
 # Setting a consistent service ID
 
-:::info**Role:** API service extender
+:::info Role: API service extender
 :::
 
 As an API service extender you can modify the service ID to ensure compatibility of services that use a non-conformant organization prefix with Zowe v2.

diff --git a/docs/user-guide/api-mediation/configuration-single-sign-on-user.md b/docs/user-guide/api-mediation/configuration-single-sign-on-user.md
@@ -1,6 +1,6 @@
 # Enabling single sign on for clients
 
-:::info**Roles:** system programmer, system administrator, security administrator
+:::info Roles: system programmer, system administrator, security administrator
 :::
 
 As a system programmer or system administrator, you can customize the way API ML handles authentication towards clients such as CLI and/or users. Each of the following methods limits the frequency the user is reqired to enter credentials to access API Mediation Layer: 

diff --git a/...e/api-mediation/configuration-unique-cookie-name-for-multiple-zowe-instances.md b/...e/api-mediation/configuration-unique-cookie-name-for-multiple-zowe-instances.md
@@ -1,6 +1,6 @@
 # Configuring a unique cookie name for a specific API ML instance
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 By default, in the API Gateway, the cookie name is `apimlAuthenticationToken`.

diff --git a/docs/user-guide/api-mediation/configuration-url-handling.md b/docs/user-guide/api-mediation/configuration-url-handling.md
@@ -1,6 +1,6 @@
 # Using encoded slashes
 
-:::info**Role:** system programmer
+:::info Role: system programmer
 :::
 
 By default, the API Mediation Layer accepts encoded slashes in the URL path of the request. If you are onboarding applications which expose endpoints that expect encoded slashes, it is necessary to keep the default configuration. We recommend that you change the property to `false` if you do not expect the applications to use the encoded slashes. 

diff --git a/docs/user-guide/api-mediation/using-multi-factor-authentication.md b/docs/user-guide/api-mediation/using-multi-factor-authentication.md
@@ -33,7 +33,7 @@ Neither Zowe CLI nor API Catalog issue a notification when a user is required to
 
 We recommend you first try to access self-service facilities and resolve the issue there. If you are unable to access your self-service facilities, contact your system administrator.
 
-:::tip**Tips:**
+:::tip Tips:
 * For more information about how to manage multi-factor authentication credentials in AAM, see [Manage Multi-Factor Authentication Credentials (IBM RACF)](https://techdocs.broadcom.com/us/en/ca-mainframe-software/security/ca-advanced-authentication-mainframe/2-0/using-with-ibm-racf/manage-multi-factor-authentication-credentials-ibm-racf.html) in the Advanced Authentication Mainframe 2.0 Broadcom documentation.
 * For more information about how to manage multi-factor authentication credentials in IBM Z MFA, see
 [IBM Z Multi-Factor Authentication](https://www.ibm.com/products/ibm-multifactor-authentication-for-zos).