diff --git a/docs/extend/extend-apiml/custom-metadata.md b/docs/extend/extend-apiml/custom-metadata.md index 43af89ece5..68a1662065 100644 --- a/docs/extend/extend-apiml/custom-metadata.md +++ b/docs/extend/extend-apiml/custom-metadata.md @@ -7,7 +7,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 - 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). + 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 [Zowe runtime](../../user-guide/install-zos.md#zowe-runtime) in Zowe server-side installation overview. ::: :::note @@ -53,7 +53,7 @@ Additional metadata can be added to the instance information that is registered * **customMetadata.apiml.corsEnabled** When this parameter is set to `true`, CORS handling by the Gateway is enabled on the service level for all service routes. - For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Cors configuration](../../user-guide/api-mediation/configuration-cors.md). + For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Customizing Cross-Origin Resource Sharing (CORS)](../../user-guide/api-mediation/configuration-cors.md). Additional information can be found in this article about [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). :::note @@ -63,7 +63,7 @@ Additional metadata can be added to the instance information that is registered * **customMetadata.apiml.gatewayAuthEndpoint** - Specifies the Gateway authentication endpoint used by the ZAAS Client configuration. The default value is `/api/v1/gateway/auth`. For more information about ZAAS Client, see [ZAAS Client](zaas-client.md) + Specifies the Gateway authentication endpoint used by the ZAAS Client configuration. The default value is `/api/v1/gateway/auth`. For more information about ZAAS Client, see [ZAAS Client](zaas-client.md). :::note If you use the Spring enabler, use the following parameter name: @@ -88,7 +88,7 @@ Additional metadata can be added to the instance information that is registered `apiml.service.customMetadata.apiml.corsAllowedOrigins` ::: - For more information, refer to enabling CORS with Custom Metadata on the Gateway: [CORS configuration](../../user-guide/api-mediation/configuration-cors.md). + For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Customizing Cross-Origin Resource Sharing (CORS)](../../user-guide/api-mediation/configuration-cors.md). * **customMetadata.apiml.lb.type** @@ -111,7 +111,7 @@ Additional metadata can be added to the instance information that is registered This value applies the Authentication load balancing schema. This is a sticky session functionality based on the ID of the user. The user ID is understood from the Zowe SSO token on the client's request. Requests without the token are routed in a round robin fashion. The user is first routed in a round robin fashion, and then the routed instance Id is cached. The instance information is used for subsequent requests to route the client to the cached target service instance. This session's default expiration time is 8 hours. After the session expires, the process initiates again. - In default configuration, this cache is stored on each Gateway instance. You can choose to distribute this cache between the Gateway's instances. To do so, follow the steps described in [Distributed load balancer cache](../../user-guide/api-mediation/configuration-distributed-load-balancer-cache). + In default configuration, this cache is stored on each Gateway instance. You can choose to distribute this cache between the Gateway's instances. To do so, follow the steps described in [Distributing the load balancer cache](../../user-guide/api-mediation/configuration-distributed-load-balancer-cache). * **customMetadata.apiml.lb.cacheRecordExpirationTimeInHours** When the property `customMetadata.apiml.lb.type` is set to `authentication`, the user can also define the expiration time for the selected instance information that is cached. This property aims to prevent any discrepancy which might occur if the required target server is no longer available. The default value is 8 hours. diff --git a/docs/extend/extend-apiml/onboard-micronaut-enabler.md b/docs/extend/extend-apiml/onboard-micronaut-enabler.md index b53f725ef2..23a8a4a793 100644 --- a/docs/extend/extend-apiml/onboard-micronaut-enabler.md +++ b/docs/extend/extend-apiml/onboard-micronaut-enabler.md @@ -287,4 +287,4 @@ Create a `logback.xml` file in the `resources` folder and include the `applicati ## Validate successful registration -After you complete the configuration, ensure that your application is visible within Zowe API ML. For more information, see the article [validating the discoverability of your API service by teh Discovery Service](onboard-spring-boot-enabler.md#validating-the-discoverability-of-your-api-service-by-the-discovery-service), which describes the validation procedure common for all enablers. +After you complete the configuration, ensure that your application is visible within Zowe API ML. For more information, see the article [validating the discoverability of your API service by the Discovery Service](onboard-spring-boot-enabler.md#validating-the-discoverability-of-your-api-service-by-the-discovery-service), which describes the validation procedure common for all enablers. diff --git a/docs/extend/extend-apiml/onboard-plain-java-enabler.md b/docs/extend/extend-apiml/onboard-plain-java-enabler.md index a33f01b436..5a4b2b471b 100644 --- a/docs/extend/extend-apiml/onboard-plain-java-enabler.md +++ b/docs/extend/extend-apiml/onboard-plain-java-enabler.md @@ -818,7 +818,7 @@ public class ApiDiscoveryListener implements ServletContextListener { Once you are able to build and start your service successfully, you can use the option of validating that your service is registered correctly with the API ML Discovery Service. **Follow these steps:** - 1. [Validate successful onboarding](./onboard-overview.md#verify-successful-onboarding-to-the-api-ml) + 1. [Validate successful onboarding](./onboard-overview.md#verify-successful-onboarding-to-the-api-ml). 2. Check that you can access your API service endpoints through the Gateway. diff --git a/docs/extend/extend-apiml/onboard-spring-boot-enabler.md b/docs/extend/extend-apiml/onboard-spring-boot-enabler.md index a017d1b94e..29bacee46a 100644 --- a/docs/extend/extend-apiml/onboard-spring-boot-enabler.md +++ b/docs/extend/extend-apiml/onboard-spring-boot-enabler.md @@ -314,7 +314,7 @@ A property notation provided in the format `-Dproperty.key=PROPERTY_VALUE` can b in any of the YAML configuration files. ### Authentication properties -These parameters are not required. If a parameter is not specified, a default value is used. See [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md/#authentication-parameters) for more details. +These parameters are not required. If a parameter is not specified, a default value is used. See [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md#authentication-parameters) for more details. ### API ML Onboarding Configuration Sample @@ -440,7 +440,7 @@ logging: ### SAF Keyring configuration You can choose to use a SAF keyring instead of keystore and truststore for storing certificates. -For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md/#zowe-api-ml-tls-requirements). For information about running Java on z/OS with a keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md). Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details. +For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md#zowe-api-ml-tls-requirements). For information about running Java on z/OS with a keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md). Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details. The following example shows enabler configuration with keyrings: ``` diff --git a/docs/extend/extend-apiml/onboard-static-definition.md b/docs/extend/extend-apiml/onboard-static-definition.md index ad643f8ef9..fce1b61bbc 100644 --- a/docs/extend/extend-apiml/onboard-static-definition.md +++ b/docs/extend/extend-apiml/onboard-static-definition.md @@ -350,13 +350,13 @@ additionalServiceMetadata: This value specifies that a service accepts PassTickets in the Authorization header of the HTTP requests using the basic authentication scheme. It is necessary to provide a service APPLID in the `apiml.authentication.applid` parameter. - **Tip:** For more information, see [Enabling PassTicket creation for API Services that accept PassTickets](authentication-for-apiml-services.md#authentication-with-passtickets). + **Tip:** For more information, see [Authentication with PassTickets](authentication-for-apiml-services.md#authentication-with-passtickets). * **safIdt** This value specifies that the application recognizes the SAF IDT scheme and fills the `X-SAF-Token` header with the token produced by the Saf IDT provider implementation. - For more information, see [SAF IDT provider](implement-new-saf-provider.md) + For more information, see [Implementing a new SAF IDT provider](implement-new-saf-provider.md). * **x509** diff --git a/docs/extend/extend-apiml/zowe-api-mediation-layer-security-overview.md b/docs/extend/extend-apiml/zowe-api-mediation-layer-security-overview.md index 1fb582bb36..b9956e0aa3 100644 --- a/docs/extend/extend-apiml/zowe-api-mediation-layer-security-overview.md +++ b/docs/extend/extend-apiml/zowe-api-mediation-layer-security-overview.md @@ -44,7 +44,7 @@ API ML uses the following authentication methods: - The client application passes the access JWT token to the API ML Gateway with subsequent requests for mainframe resources. - API ML federates the user identities and calls the requested resource with appropriate mainframe user credentials. -For more information, see the detailed explanation of the [OIDC authentication and Identity Federation](api-mediation-oidc-authentication.md) +For more information, see the detailed explanation of the [OIDC authentication and Identity Federation](api-mediation-oidc-authentication.md). ### Zowe API ML services