[7.x] [DOCS] Fixes broken links (#51634) (#51771)

docs/api/role-management/put.asciidoc

@@ -26,7 +26,9 @@ To use the create or update role API, you must have the `manage_security` cluste
   (Optional, object) In the `metadata` object, keys that begin with `_` are reserved for system usage.
 
 `elasticsearch`:: 
-  (Optional, object) {es} cluster and index privileges. Valid keys include `cluster`, `indices`, and `run_as`. For more information, see {xpack-ref}/defining-roles.html[Defining Roles].
+  (Optional, object) {es} cluster and index privileges. Valid keys include 
+  `cluster`, `indices`, and `run_as`. For more information, see
+  {ref}/defining-roles.html[Defining roles].
 
 `kibana`:: 
   (list) Objects that specify the <<kibana-privileges, Kibana privileges>> for the role:

docs/developer/security/rbac.asciidoc

@@ -1,7 +1,14 @@
 [[development-security-rbac]]
 === Role-based access control
 
-Role-based access control (RBAC) in {kib} relies upon the {xpack-ref}/security-privileges.html#application-privileges[application privileges] that Elasticsearch exposes. This allows {kib} to define the privileges that {kib} wishes to grant to users, assign them to the relevant users using roles, and then authorize the user to perform a specific action. This is handled within a secured instance of the `SavedObjectsClient` and available transparently to consumers when using `request.getSavedObjectsClient()` or `savedObjects.getScopedSavedObjectsClient()`.
+Role-based access control (RBAC) in {kib} relies upon the
+{ref}/security-privileges.html#application-privileges[application privileges]
+that Elasticsearch exposes. This allows {kib} to define the privileges that
+{kib} wishes to grant to users, assign them to the relevant users using roles,
+and then authorize the user to perform a specific action. This is handled within
+a secured instance of the `SavedObjectsClient` and available transparently to
+consumers when using `request.getSavedObjectsClient()` or 
+`savedObjects.getScopedSavedObjectsClient()`.
 
 [[development-rbac-privileges]]
 ==== {kib} Privileges

docs/getting-started/tutorial-full-experience.asciidoc

@@ -91,7 +91,7 @@ and whether it's _tokenized_, or broken up into separate words.
 
 NOTE: If security is enabled, you must have the `all` Kibana privilege to run this tutorial.
 You must also have the `create`, `manage` `read`, `write,` and `delete` 
-index privileges. See {xpack-ref}/security-privileges.html[Security Privileges] 
+index privileges. See {ref}/security-privileges.html[Security privileges] 
 for more information.
 
 In Kibana *Dev Tools > Console*, set up a mapping for the Shakespeare data set:

docs/getting-started/tutorial-sample-data.asciidoc

@@ -12,8 +12,8 @@ with Kibana sample data and learn to:
 
 
 NOTE: If security is enabled, you must have `read`, `write`, and `manage` privileges
-on the `kibana_sample_data_*` indices. See {xpack-ref}/security-privileges.html[Security Privileges] 
-for more information.
+on the `kibana_sample_data_*` indices. See
+{ref}/security-privileges.html[Security privileges] for more information.
 
 
 [float]

docs/management/managing-indices.asciidoc

@@ -22,7 +22,7 @@ If security is enabled,
 you must have the `monitor` cluster privilege and the `view_index_metadata` 
 and `manage` index privileges to view the data.  
 For index templates, you must have the `manage_index_templates` cluster privilege.
-See {xpack-ref}/security-privileges.html[Security Privileges] for more
+See {ref}/security-privileges.html[Security privileges] for more
 information.
 
 Before using this feature, you should be familiar with index management 

docs/redirects.asciidoc

@@ -39,7 +39,7 @@ This page has moved. Please see <<xpack-logs-configuring>>.
 == Creating {transforms}
 
 This page is deleted. Please see
-{stack-ov}/ecommerce-dataframes.html[Transforming the eCommerce sample data].
+{ref}/ecommerce-transforms.html[Transforming the eCommerce sample data].
 
 [role="exclude",id="ml-jobs"]
 == Creating {anomaly-jobs}

docs/setup/install.asciidoc

@@ -54,8 +54,8 @@ Formulae are available from the Elastic Homebrew tap for installing {kib} on mac
 <<brew>>
 
 IMPORTANT: If your Elasticsearch installation is protected by
-{xpack-ref}/elasticsearch-security.html[{security}] see
-{kibana-ref}/using-kibana-with-security.html[Configuring Security in Kibana] for
+{ref}/elasticsearch-security.html[{security}] see
+{kibana-ref}/using-kibana-with-security.html[Configuring security in Kibana] for
 additional setup instructions.
 
 include::install/targz.asciidoc[]

docs/user/security/authentication/index.asciidoc

@@ -14,16 +14,17 @@
 - <<oidc>>
 
 [[basic-authentication]]
-==== Basic Authentication
+==== Basic authentication
 
 Basic authentication requires a username and password to successfully log in to {kib}. It is enabled by default and based on the Native security realm provided by {es}. The basic authentication provider uses a Kibana provided login form, and supports authentication using the `Authorization` request header's `Basic` scheme.
 
 The session cookies that are issued by the basic authentication provider are stateless. Therefore, logging out of Kibana when using the basic authentication provider clears the session cookies from the browser but does not invalidate the session cookie for reuse.
 
-For more information about basic authentication and built-in users, see {xpack-ref}/setting-up-authentication.html[Setting Up User Authentication].
+For more information about basic authentication and built-in users, see
+{ref}/setting-up-authentication.html[User authentication].
 
 [[token-authentication]]
-==== Token Authentication
+==== Token authentication
 
 Token authentication allows users to login using the same Kibana provided login form as basic authentication. The token authentication provider is built on {es}'s token APIs. The bearer tokens returned by {es}'s {ref}/security-api-get-token.html[get token API] can be used directly with Kibana using the `Authorization` request header with the `Bearer` scheme.
 
@@ -46,7 +47,7 @@ xpack.security.authc.providers: [token, basic]
 --------------------------------------------------------------------------------
 
 [[pki-authentication]]
-==== Public Key Infrastructure (PKI) Authentication
+==== Public key infrastructure (PKI) authentication
 
 [IMPORTANT]
 ============================================================================
@@ -76,9 +77,9 @@ xpack.security.authc.providers: [pki, basic]
 Note that with `server.ssl.clientAuthentication` set to `required`, users are asked to provide a valid client certificate, even if they want to authenticate with username and password. Depending on the security policies, it may or may not be desired. If not, `server.ssl.clientAuthentication` can be set to `optional`. In this case, {kib} still requests a client certificate, but the client won't be required to present one. The `optional` client authentication mode might also be needed in other cases, for example, when PKI authentication is used in conjunction with Reporting.
 
 [[saml]]
-==== SAML Single Sign-On
+==== SAML single sign-on
 
-SAML authentication allows users to log in to {kib} with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in {es} before setting it up in {kib}. See {xpack-ref}/saml-guide.html[Configuring SAML Single-Sign-On on the Elastic Stack].
+SAML authentication allows users to log in to {kib} with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in {es} before setting it up in {kib}. See {ref}/saml-guide.html[Configuring SAML single sign-on on the Elastic Stack].
 
 Set the configuration values in `kibana.yml` as follows:
 
@@ -106,7 +107,7 @@ server.xsrf.whitelist: [/api/security/saml/callback]
 Users will be able to log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} URL. Users who aren't authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force user to re-authenticate. This login scenario is called _Service Provider initiated login_.
 
 [float]
-===== SAML and Basic Authentication
+===== SAML and basic authentication
 
 SAML support in {kib} is designed to be the primary (or sole) authentication method for users of that {kib} instance. However, you can configure both SAML and Basic authentication for the same {kib} instance:
 
@@ -135,7 +136,7 @@ xpack.security.authc.saml.maxRedirectURLSize: 1kb
 --------------------------------------------------------------------------------
 
 [[oidc]]
-==== OpenID Connect Single Sign-On
+==== OpenID Connect single sign-on
 
 Similar to SAML, authentication with OpenID Connect allows users to log in to {kib} using an OpenID Connect Provider such as Google, or Okta. OpenID Connect
 should also be configured in {es}. For more details, see {ref}/oidc-guide.html[Configuring single sign-on to the {stack} using OpenID Connect].
@@ -166,7 +167,7 @@ server.xsrf.whitelist: [/api/security/v1/oidc]
 --------------------------------------------------------------------------------
 
 [float]
-===== OpenID Connect and Basic Authentication
+===== OpenID Connect and basic authentication
 
 Similar to SAML, OpenID Connect support in {kib} is designed to be the primary (or sole) authentication method for users
 of that {kib} instance. However, you can configure both OpenID Connect and Basic authentication for the same {kib} instance:
@@ -179,12 +180,12 @@ xpack.security.authc.providers: [oidc, basic]
 Users will be able to access the login page and use Basic authentication by navigating to the `/login` URL.
 
 [float]
-==== Single Sign-On provider details
+==== Single sign-on provider details
 
 The following sections apply both to <<saml>> and <<oidc>> 
 
 [float]
-===== Access and Refresh Tokens
+===== Access and refresh tokens
 
 Once the user logs in to {kib} Single Sign-On, either using SAML or OpenID Connect, {es} issues access and refresh tokens
 that {kib} encrypts and stores them in its own session cookie. This way, the user isn't redirected to the Identity Provider
@@ -202,7 +203,7 @@ If {kib} can't redirect the user to the external authentication provider (for ex
 indicates that both access and refresh tokens are expired. Reloading the current {kib} page fixes the error.
 
 [float]
-===== Local and Global Logout
+===== Local and global logout
 
 During logout, both the {kib} session cookie and access/refresh token pair are invalidated. Even if the cookie has been
 leaked, it can't be re-used after logout. This is known as "local" logout.

docs/user/security/reporting.asciidoc

@@ -8,7 +8,7 @@ user actions in {kib}.
 To use {reporting} with {security} enabled, you need to
 <<using-kibana-with-security,set up {kib} to work with {security}>>.
 If you are automatically generating reports with
-{xpack-ref}/xpack-alerting.html[{watcher}], you also need to configure {watcher}
+{ref}/xpack-alerting.html[{watcher}], you also need to configure {watcher}
 to trust the {kib} server's certificate. For more information, see
 <<securing-reporting>>.
 
@@ -35,7 +35,7 @@ POST /_security/user/reporter
 * If you are using an LDAP or Active Directory realm, you can either assign
 roles on a per user basis, or assign roles to groups of users. By default, role
 mappings are configured in
-{xpack-ref}/mapping-roles.html[`config/shield/role_mapping.yml`].
+{ref}/mapping-roles.html[`config/shield/role_mapping.yml`].
 For example, the following snippet assigns the user named Bill Murray the
 `kibana_user` and `reporting_user` roles:
 +
@@ -55,7 +55,7 @@ In a production environment, you should restrict access to
 the {reporting} endpoints to authorized users. This requires that you:
 
 . Enable {security} on your {es} cluster. For more information,
-see {xpack-ref}/security-getting-started.html[Getting Started with Security].
+see {ref}/security-getting-started.html[Getting Started with Security].
 . Configure an SSL certificate for Kibana. For more information, see
 <<using-kibana-with-security>>.
 . Configure {watcher} to trust the Kibana server's certificate by adding it to
@@ -83,4 +83,4 @@ includes a watch that submits requests as the built-in `elastic` user:
 <<automating-report-generation>>.
 
 For more information about configuring watches, see
-{xpack-ref}/how-watcher-works.html[How Watcher Works].
+{ref}/how-watcher-works.html[How Watcher works].

docs/user/security/securing-kibana.asciidoc

@@ -121,7 +121,7 @@ TIP: You can define as many different roles for your {kib} users as you need.
 
 For example, create roles that have `read` and `view_index_metadata` privileges
 on specific index patterns. For more information, see
-{xpack-ref}/authorization.html[Configuring Role-based Access Control].
+{ref}/authorization.html[User authorization].
 
 --