[DOCS] Removes duplicated authentication pages

x-pack/docs/en/security/authentication/active-directory-realm.asciidoc

@@ -1,78 +0,0 @@
-[role="xpack"]
-[[active-directory-realm]]
-=== Active Directory user authentication
-
-You can configure {security} to communicate with Active Directory to authenticate
-users. To integrate with Active Directory, you configure an `active_directory`
-realm and map Active Directory users and groups to {security} roles in the
-<<mapping-roles, role mapping file>>.
-
-See {ref}/configuring-ad-realm.html[Configuring an Active Directory Realm].
-
-{security} uses LDAP to communicate with Active Directory, so `active_directory`
-realms are similar to <<ldap-realm, `ldap` realms>>. Like LDAP directories,
-Active Directory stores users and groups hierarchically. The directory's
-hierarchy is built from containers such as the _organizational unit_ (`ou`),
-_organization_ (`o`), and _domain controller_ (`dc`).
-
-The path to an entry is a _Distinguished Name_ (DN) that uniquely identifies a
-user or group. User and group names typically have attributes such as a
-_common name_ (`cn`) or _unique ID_ (`uid`). A DN is specified as a string, for
-example `"cn=admin,dc=example,dc=com"` (white spaces are ignored).
-
-{security} only supports Active Directory security groups. You cannot map
-distribution groups to roles.
-
-NOTE: When you use Active Directory for authentication, the username entered by
-      the user is expected to match the `sAMAccountName` or `userPrincipalName`,
-      not the common name.
-
-The Active Directory realm authenticates users using an LDAP bind request. After
-authenticating the user, the realm then searches to find the user's entry in
-Active Directory. Once the user has been found, the Active Directory realm then
-retrieves the user's group memberships from the `tokenGroups` attribute on the
-user's entry in Active Directory.
-
-[[ad-load-balancing]]
-==== Load balancing and failover
-The `load_balance.type` setting can be used at the realm level to configure how
-{security} should interact with multiple Active Directory servers. Two modes of
-operation are supported: failover and load balancing.
-
-See {ref}/security-settings.html#load-balancing[Load Balancing and Failover Settings].
-
-[[ad-settings]]
-==== Active Directory realm settings
-
-See {ref}/security-settings.html#ref-ad-settings[Active Directory Realm Settings].
-
-[[mapping-roles-ad]]
-==== Mapping Active Directory users and groups to roles
-
-See {ref}/configuring-ad-realm.html[Configuring an Active Directory realm]. 
-
-[[ad-user-metadata]]
-==== User metadata in Active Directory realms
-When a user is authenticated via an Active Directory realm, the following
-properties are populated in the user's _metadata_:
-
-|=======================
-| Field               | Description
-| `ldap_dn`           | The distinguished name of the user.
-| `ldap_groups`       | The distinguished name of each of the groups that were
-                        resolved for the user (regardless of whether those
-                        groups were mapped to a role).
-|=======================
-
-This metadata is returned in the 
-{ref}/security-api-authenticate.html[authenticate API] and can be used with
-<<templating-role-query, templated queries>> in roles.
-
-Additional metadata can be extracted from the Active Directory server by configuring
-the `metadata` setting on the Active Directory realm.
-
-[[active-directory-ssl]]
-==== Setting up SSL between Elasticsearch and Active Directory
-
-See 
-{ref}/configuring-tls.html#tls-active-directory[Encrypting communications between {es} and Active Directory].

x-pack/docs/en/security/authentication/built-in-users.asciidoc

@@ -1,157 +0,0 @@
-[role="xpack"]
-[[built-in-users]]
-=== Built-in users
-
-{security} provides built-in user credentials to help you get up and running.
-These users have a fixed set of privileges and cannot be authenticated until their
-passwords have been set. The `elastic` user can be used to
-<<set-built-in-user-passwords,set all of the built-in user passwords>>.
-
-`elastic`:: A built-in _superuser_. See <<built-in-roles>>.
-`kibana`:: The user Kibana uses to connect and communicate with Elasticsearch.
-`logstash_system`:: The user Logstash uses when storing monitoring information in Elasticsearch.
-`beats_system`:: The user the Beats use when storing monitoring information in Elasticsearch.
-
-
-[float]
-[[built-in-user-explanation]]
-==== How the built-in users work
-These built-in users are stored within a special `.security` index managed by
-{security}.
-This means that, if the password is changed, or a user is disabled, then that
-change is automatically reflected on each node in the cluster. It also means
-that if your `.security` index is deleted, or restored from a snapshot, then
-any changes you have applied will be lost.
-
-Although they share the same API, the built-in users are separate and distinct
-from users managed by the <<native-realm, native realm>>. Disabling the native
-realm will not have any effect on the built-in users. The built-in users can
-be disabled individually, using the
-{ref}/security-api-users.html[user management API].
-
-[float]
-[[bootstrap-elastic-passwords]]
-==== The Elastic bootstrap password
-
-When you install {es}, if the `elastic` user does not already have a password,
-it uses a default bootstrap password. The bootstrap password is a transient
-password that enables you to run the tools that set all the built-in user passwords.
-
-By default, the bootstrap password is derived from a randomized `keystore.seed`
-setting, which is added to the keystore during installation. You do not need
-to know or change this bootstrap password. If you have defined a
-`bootstrap.password` setting in the keystore, however, that value is used instead.
-For more information about interacting with the keystore, see
-{ref}/secure-settings.html[Secure Settings].
-
-NOTE: After you <<set-built-in-user-passwords,set passwords for the built-in users>>,
-in particular for the `elastic` user, there is no further use for the bootstrap
-password.
-
-[float]
-[[set-built-in-user-passwords]]
-==== Setting built-in user passwords
-
-You must set the passwords for all built-in users.
-
-The +elasticsearch-setup-passwords+ tool is the simplest method to set the
-built-in users' passwords for the first time. It uses the `elastic` user's
-bootstrap password to run user management API requests. For example, you can run
-the command in an "interactive" mode, which prompts you to enter new passwords
-for the `elastic`, `kibana`, `logstash_system`, and `beats_system` users:
-
-[source,shell]
---------------------------------------------------
-bin/elasticsearch-setup-passwords interactive
---------------------------------------------------
-
-For more information about the command options, see
-{ref}/setup-passwords.html[elasticsearch-setup-passwords].
-
-IMPORTANT: After you set a password for the `elastic` user, the bootstrap
-password is no longer valid; you cannot run the `elasticsearch-setup-passwords`
-command a second time.
-
-Alternatively, you can set the initial passwords for the built-in users by using
-the *Management > Users* page in {kib} or the
-{ref}/security-api-change-password.html[Change Password API]. These methods are
-more complex. You must supply the `elastic` user and its bootstrap password to
-log into {kib} or run the API. This requirement means that you cannot use the
-default bootstrap password that is derived from the `keystore.seed` setting.
-Instead, you must explicitly set a `bootstrap.password` setting in the keystore
-before you start {es}. For example, the following command prompts you to enter a
-new bootstrap password:
-
-[source,shell]
-----------------------------------------------------
-bin/elasticsearch-keystore add "bootstrap.password"
-----------------------------------------------------
-
-You can then start {es} and {kib} and use the `elastic` user and bootstrap
-password to log into {kib} and change the passwords. Alternatively, you can
-submit Change Password API requests for each built-in user. These methods are
-better suited for changing your passwords after the initial setup is complete,
-since at that point the bootstrap password is no longer required.
-
-[float]
-[[add-built-in-user-passwords]]
-==== Adding Built-in User Passwords To {kib}, Logstash, and Beats
-
-After the `kibana` user password is set, you need to update the {kib} server
-with the new password by setting `elasticsearch.password` in the `kibana.yml`
-configuration file:
-
-[source,yaml]
------------------------------------------------
-elasticsearch.password: kibanapassword
------------------------------------------------
-
-The `logstash_system` user is used internally within Logstash when
-monitoring is enabled for Logstash.
-
-To enable this feature in Logstash, you need to update the Logstash
-configuration with the new password by setting `xpack.monitoring.elasticsearch.password` in
-the `logstash.yml` configuration file:
-
-[source,yaml]
-----------------------------------------------------------
-xpack.monitoring.elasticsearch.password: logstashpassword
-----------------------------------------------------------
-
-If you have upgraded from an older version of Elasticsearch,
-the `logstash_system` user may have defaulted to _disabled_ for security reasons.
-Once the password has been changed, you can enable the user via the following API call:
-
-[source,js]
----------------------------------------------------------------------
-PUT _xpack/security/user/logstash_system/_enable
----------------------------------------------------------------------
-// CONSOLE
-
-The `beats_system` user is used internally within Beats when monitoring is
-enabled for Beats.
-
-To enable this feature in Beats, you need to update the configuration for each
-of your beats to reference the correct username and password. For example:
-
-[source,yaml]
-----------------------------------------------------------
-xpack.monitoring.elasticsearch.username: beats_system
-xpack.monitoring.elasticsearch.password: beatspassword
-----------------------------------------------------------
-
-If you have upgraded from an older version of {es}, then you may not have set a
-password for the `beats_system` user. If this is the case, then you should use
-the *Management > Users* page in {kib} or the
-{ref}/security-api-change-password.html[Change Password API] to set a password
-for this user.
-
-[float]
-[[disabling-default-password]]
-==== Disabling default password functionality
-[IMPORTANT]
-=============================================================================
-This setting is deprecated. The elastic user no longer has a default password.
-The password must be set before the user can be used.
-See <<bootstrap-elastic-passwords>>.
-=============================================================================

x-pack/docs/en/security/authentication/custom-realm.asciidoc

@@ -1,100 +0,0 @@
-[role="xpack"]
-[[custom-realms]]
-=== Integrating with other authentication systems
-
-If you are using an authentication system that is not supported out-of-the-box
-by {security}, you can create a custom realm to interact with it to authenticate
-users. You implement a custom realm as an SPI loaded security extension
-as part of an ordinary elasticsearch plugin.
-
-[[implementing-custom-realm]]
-==== Implementing a custom realm
-
-Sample code that illustrates the structure and implementation of a custom realm
-is provided in the https://github.com/elastic/shield-custom-realm-example[custom-realm-example]
-repository on GitHub. You can use this code as a starting point for creating your
-own realm.
-
-To create a custom realm, you need to:
-
-. Extend `org.elasticsearch.xpack.security.authc.Realm` to communicate with your
-  authentication system to authenticate users.
-. Implement the `org.elasticsearch.xpack.security.authc.Realm.Factory` interface in
-  a class that will be used to create the custom realm.
-. Extend `org.elasticsearch.xpack.security.authc.DefaultAuthenticationFailureHandler` to
-  handle authentication failures when using your custom realm.
-
-To package your custom realm as a plugin:
-
-. Implement an extension class for your realm that extends
-  `org.elasticsearch.xpack.core.security.SecurityExtension`. There you need to
-  override one or more of the following methods:
-+
-[source,java]
-----------------------------------------------------
-@Override
-public Map<String, Factory> getRealms() {
-    ...
-}
-----------------------------------------------------
-+
-The `getRealms` method is used to provide a map of type names to the `Factory` that
-will be used to create the realm.
-+
-[source,java]
-----------------------------------------------------
-@Override
-public AuthenticationFailureHandler getAuthenticationFailureHandler() {
-    ...
-}
-----------------------------------------------------
-+
-The `getAuthenticationFailureHandler` method is used to optionally provide a
-custom `AuthenticationFailureHandler`, which will control how {security} responds
-in certain authentication failure events.
-+
-[source,java]
-----------------------------------------------------
-@Override
-public List<String> getSettingsFilter() {
-    ...
-}
-----------------------------------------------------
-+
-The `Plugin#getSettingsFilter` method returns a list of setting names that should be
-filtered from the settings APIs as they may contain sensitive credentials. Note this method is not
-part of the `SecurityExtension` interface, it's available as part of the elasticsearch plugin main class.
-
-. Create a build configuration file for the plugin; Gradle is our recommendation.
-. Create a `META-INF/services/org.elasticsearch.xpack.core.security.SecurityExtension` descriptor file for the
-  extension that contains the fully qualified class name of your `org.elasticsearch.xpack.core.security.SecurityExtension` implementation
-. Bundle all in a single zip file.
-
-[[using-custom-realm]]
-==== Using a custom realm to authenticate users
-
-To use a custom realm:
-
-. Install the realm extension on each node in the cluster. You run
-  `bin/elasticsearch-plugin` with the `install` sub-command and specify the URL
-  pointing to the zip file that contains the extension. For example:
-+
-[source,shell]
-----------------------------------------
-bin/elasticsearch-plugin install file:///<path>/my-realm-1.0.zip
-----------------------------------------
-
-. Add a realm configuration of the appropriate realm type to `elasticsearch.yml`
-under the `xpack.security.authc.realms` namespace. The options you can set depend
-on the settings exposed by the custom realm. At a minimum, you must set the realm
-`type` to the type defined by the extension. If you are configuring multiple
-realms, you should also explicitly set the  `order` attribute to control the
-order in which the realms are consulted during authentication. You should make
-sure each configured realm has a distinct `order` setting. In the event that
-two or more realms have the same `order`, they will be processed in realm `name` order.
-+
-IMPORTANT: When you configure realms in `elasticsearch.yml`, only the
-realms you specify are used for authentication. If you also want to use the
-`native` or `file` realms, you must include them in the realm chain.
-
-. Restart Elasticsearch.

x-pack/docs/en/security/authentication/file-realm.asciidoc

@@ -1,27 +0,0 @@
-[role="xpack"]
-[[file-realm]]
-=== File-based user authentication
-
-You can manage and authenticate users with the built-in `file` realm.
-With the `file` realm, users are defined in local files on each node in the cluster.
-
-IMPORTANT:  As the administrator of the cluster, it is your responsibility to
-            ensure the same users are defined on every node in the cluster.
-            {security} does not deliver any mechanism to guarantee this.
-
-The `file` realm is primarily supported to serve as a fallback/recovery realm. It
-is mostly useful in situations where all users locked themselves out of the system
-(no one remembers their username/password). In this type of scenarios, the `file`
-realm is your only way out - you can define a new `admin` user in the `file` realm
-and use it to log in and reset the credentials of all other users.
-
-IMPORTANT: When you configure realms in `elasticsearch.yml`, only the
-realms you specify are used for authentication. To use the
-`file` realm as a fallback, you must include it in the realm chain.
-
-To define users, {security} provides the {ref}/users-command.html[users]
-command-line tool. This tool enables you to add and remove users, assign user
-roles, and manage user passwords.
-
-For more information, see 
-{ref}/configuring-file-realm.html[Configuring a file realm].

x-pack/docs/en/security/authentication/internal-users.asciidoc

@@ -1,13 +0,0 @@
-[role="xpack"]
-[[internal-users]]
-=== Internal users
-
-{security} has three _internal_ users (`_system`, `_xpack`, and `_xpack_security`)
-that are responsible for the operations that take place inside an {es} cluster.
-
-These users are only used by requests that originate from within the cluster.
-For this reason, they cannot be used to authenticate against the API and there
-is no password to manage or reset.
-
-From time-to-time you may find a reference to one of these users inside your
-logs, including <<auditing, audit logs>>.

x-pack/docs/en/security/authentication/ldap-realm.asciidoc

@@ -1,86 +0,0 @@
-[role="xpack"]
-[[ldap-realm]]
-=== LDAP user authentication
-
-You can configure {security} to communicate with a Lightweight Directory Access
-Protocol (LDAP) server to authenticate users. To integrate with LDAP, you
-configure an `ldap` realm and map LDAP groups to user roles in the
-<<mapping-roles, role mapping file>>.
-
-LDAP stores users and groups hierarchically, similar to the way folders are
-grouped in a file system. An LDAP directory's hierarchy is built from containers
-such as the _organizational unit_ (`ou`), _organization_ (`o`), and
-_domain controller_ (`dc`).
-
-The path to an entry is a _Distinguished Name_ (DN) that uniquely identifies a
-user or group. User and group names typically have attributes such as a
-_common name_ (`cn`) or _unique ID_ (`uid`). A DN is specified as a string,
-for example  `"cn=admin,dc=example,dc=com"` (white spaces are ignored).
-
-The `ldap` realm supports two modes of operation, a user search mode
-and a mode with specific templates for user DNs. 
-
-[[ldap-user-search]]
-==== User search mode and user DN templates mode
-
-See {ref}/configuring-ldap-realm.html[Configuring an LDAP Realm].
-
-[[ldap-load-balancing]]
-==== Load balancing and failover
-The `load_balance.type` setting can be used at the realm level to configure how
-{security} should interact with multiple LDAP servers. {security} supports both
-failover and load balancing modes of operation.
-
-See {ref}/security-settings.html#load-balancing[Load Balancing and Failover Settings].
-
-[[ldap-settings]]
-==== LDAP realm settings
-
-See {ref}/security-settings.html#ref-ldap-settings[LDAP Realm Settings].
-
-[[mapping-roles-ldap]]
-==== Mapping LDAP groups to roles
-
-An integral part of a realm authentication process is to resolve the roles
-associated with the authenticated user. Roles define the privileges a user has
-in the cluster.
-
-Since with the `ldap` realm the users are managed externally in the LDAP server,
-the expectation is that their roles are managed there as well. If fact, LDAP
-supports the notion of groups, which often represent user roles for different
-systems in the organization.
-
-The `ldap` realm enables you to map LDAP users to to roles via their LDAP
-groups, or other metadata. This role mapping can be configured via the
-{ref}/security-api-role-mapping.html[role-mapping API], or by using a file stored
-on each node. When a user authenticates with LDAP, the privileges
-for that user are the union of all privileges defined by the roles to which
-the user is mapped. For more information, see 
-{ref}/configuring-ldap-realm.html[Configuring an LDAP Realm].
-
-[[ldap-user-metadata]]
-==== User metadata in LDAP realms
-When a user is authenticated via an LDAP realm, the following properties are
-populated in the user's _metadata_:
-
-|=======================
-| Field               | Description
-| `ldap_dn`           | The distinguished name of the user.
-| `ldap_groups`       | The distinguished name of each of the groups that were
-                        resolved for the user (regardless of whether those
-                        groups were mapped to a role).
-|=======================
-
-This metadata is returned in the
-{ref}/security-api-authenticate.html[authenticate API], and can be used with
-<<templating-role-query, templated queries>> in roles.
-
-Additional fields can be included in the user's metadata by  configuring
-the `metadata` setting on the LDAP realm. This metadata is available for use
-with the <<mapping-roles-api, role mapping API>> or in
-<<templating-role-query, templated role queries>>.
-
-[[ldap-ssl]]
-==== Setting up SSL Between Elasticsearch and LDAP
-
-See {ref}/configuring-tls.html#tls-ldap[Encrypting Communications Between {es} and LDAP]. 

x-pack/docs/en/security/authentication/native-realm.asciidoc

@@ -1,31 +0,0 @@
-[role="xpack"]
-[[native-realm]]
-=== Native user authentication
-
-The easiest way to manage and authenticate users is with the internal `native`
-realm. You can use the REST APIs or Kibana to add and remove users, assign user roles, and
-manage user passwords.
-
-[[native-realm-configuration]]
-[float]
-==== Configuring a native realm
-
-See {ref}/configuring-native-realm.html[Configuring a native realm]. 
-
-[[native-settings]]
-==== Native realm settings
-
-See {ref}/security-settings.html#ref-native-settings[Native realm settings]. 
-
-[[managing-native-users]]
-==== Managing native users
-
-{security} enables you to easily manage users in {kib} on the 
-*Management / Security / Users* page. 
-
-Alternatively, you can manage users through the `user` API. For more 
-information and examples, see {ref}/security-api-users.html[User management APIs].
-
-[[migrating-from-file]]
-NOTE: To migrate file-based users to the `native` realm, use the
-{ref}/migrate-tool.html[migrate tool].

x-pack/docs/en/security/authentication/overview.asciidoc

@@ -1,64 +0,0 @@
-[role="xpack"]
-[[setting-up-authentication]]
-== User authentication
-
-Authentication identifies an individual. To gain access to restricted resources,
-a user must prove their identity, via passwords, credentials, or some other
-means (typically referred to as authentication tokens).
-
-The {stack} authenticates users by identifying the users behind the requests
-that hit the cluster and verifying that they are who they claim to be. The
-authentication process is handled by one or more authentication services called
-<<realms,_realms_>>. 
-
-You can use the native support for managing and authenticating users, or
-integrate with external user management systems such as LDAP and Active
-Directory. 
-
-{security} provides built-in realms such as `native`,`ldap`, `active_directory`, 
-`pki`, `file`, and `saml`. If none of the built-in realms meet your needs, you 
-can also build your own custom realm and plug it into the {stack}. 
-
-When {security} is enabled, depending on the realms you've configured, you must 
-attach your user credentials to the requests sent to {es}. For example, when 
-using realms that support usernames and passwords you can simply attach 
-{wikipedia}/Basic_access_authentication[basic auth] header to the requests.
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/built-in-users.asciidoc
-include::built-in-users.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/internal-users.asciidoc
-include::internal-users.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/realms.asciidoc
-include::realms.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/active-directory-realm.asciidoc
-include::active-directory-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/file-realm.asciidoc
-include::file-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/ldap-realm.asciidoc
-include::ldap-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/native-realm.asciidoc
-include::native-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/pki-realm.asciidoc
-include::pki-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/saml-realm.asciidoc
-include::saml-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/custom-realm.asciidoc
-include::custom-realm.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/anonymous-access.asciidoc
-include::anonymous-access.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/user-cache.asciidoc
-include::user-cache.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/saml-guide.asciidoc
-include::saml-guide.asciidoc[]

x-pack/docs/en/security/authentication/pki-realm.asciidoc

@@ -1,21 +0,0 @@
-[role="xpack"]
-[[pki-realm]]
-=== PKI user authentication
-
-You can configure {security} to use Public Key Infrastructure (PKI) certificates
-to authenticate users in {es}. This requires clients to present X.509
-certificates.
-
-NOTE: You cannot use PKI certificates to authenticate users in {kib}.
-
-To use PKI in {es}, you configure a PKI realm, enable client authentication on
-the desired network layers (transport or http), and map the Distinguished Names
-(DNs) from the user certificates to {security} roles in the
-<<mapping-roles, role mapping file>>.
-
-See {ref}/configuring-pki-realm.html[Configuring a PKI realm].
-
-[[pki-settings]]
-==== PKI realm settings
-
-See {ref}/security-settings.html#ref-pki-settings[PKI realm settings].

x-pack/docs/en/security/authentication/realms.asciidoc

@@ -1,124 +0,0 @@
-[role="xpack"]
-[[realms]]
-=== Realms
-
-Authentication in {security} is handled by one or more authentication services
-called _realms_. A _realm_ is used to resolve and authenticate users based on
-authentication tokens. {security} provides the following built-in realms:
-
-_native_::
-An internal realm where users are stored in a dedicated {es} index.
-This realm supports an authentication token in the form of username and password,
-and is available by default when no realms are explicitly configured. The users
-are managed via the {ref}/security-api-users.html[User Management API]. See
-<<native-realm>>.
-
-_ldap_::
-A realm that uses an external LDAP server to authenticate the
-users. This realm supports an authentication token in the form of username and
-password, and requires explicit configuration in order to be used. See
-<<ldap-realm>>.
-
-_active_directory_::
-A realm that uses an external Active Directory Server to authenticate the
-users. With this realm, users are authenticated by usernames and passwords.
-See <<active-directory-realm>>.
-
-_pki_::
-A realm that authenticates users using Public Key Infrastructure (PKI). This
-realm works in conjunction with SSL/TLS and identifies the users through the
-Distinguished Name (DN) of the client's X.509 certificates. See <<pki-realm>>.
-
-_file_::
-An internal realm where users are defined in files stored on each node in the
-{es} cluster. This realm supports an authentication token in the form
-of username and password and is always available. See <<file-realm>>.
-
-_saml_::
-A realm that facilitates authentication using the SAML 2.0 Web SSO protocol.
-This realm is designed to support authentication through {kib} and is not
-intended for use in the REST API.  See <<saml-realm>>.
-
-{security} also supports custom realms. If you need to integrate with another
-authentication system, you can build a custom realm plugin. For more information,
-see <<custom-realms, Integrating with Other Authentication Systems>>.
-
-Realms live within a _realm chain_. It is essentially a prioritized list of
-configured realms (typically of various types). The order of the list determines
-the order in which the realms will be consulted. You should make sure each
-configured realm has a distinct `order` setting. In the event that two or more
-realms have the same `order`, they will be processed in `name` order.
-During the authentication process, {security} will consult and try to
-authenticate the request one realm at a time.
-Once one of the realms successfully authenticates the request, the authentication
-is considered to be successful and the authenticated user will be associated
-with the request (which will then proceed to the authorization phase). If a realm
-cannot authenticate the request, the next in line realm in the chain will be
-consulted. If all realms in the chain could not authenticate the request, the
-authentication is then considered to be unsuccessful and an authentication error
-will be returned (as HTTP status code `401`).
-
-NOTE: Some systems (e.g. Active Directory) have a temporary lock-out period after
-      several successive failed login attempts. If the same username exists in
-      multiple realms, unintentional account lockouts are possible. For more
-      information, please see <<trouble-shoot-active-directory, here>>.
-
-The default realm chain contains the `native` and `file` realms. To explicitly,
-configure a realm chain, you specify the chain in `elasticsearch.yml`. When you
-configure a realm chain, only the realms you specify are used for authentication.
-To use the `native` and `file` realms, you must include them in the chain.
-
-The following snippet configures a realm chain that includes the `file` and
-`native` realms, as well as two LDAP realms and an Active Directory realm.
-
-[source,yaml]
-----------------------------------------
-xpack.security.authc:
-  realms:
-
-    file:
-      type: file
-      order: 0
-
-    native:
-      type: native
-      order: 1
-
-    ldap1:
-      type: ldap
-      order: 2
-      enabled: false
-      url: 'url_to_ldap1'
-      ...
-
-    ldap2:
-      type: ldap
-      order: 3
-      url: 'url_to_ldap2'
-      ...
-
-    ad1:
-      type: active_directory
-      order: 4
-      url: 'url_to_ad'
-----------------------------------------
-
-As can be seen above, each realm has a unique name that identifies it and each
-realm type dictates its own set of required and optional settings. That said,
-there are 
-{ref}/security-settings.html#ref-realm-settings[settings that are common to all realms]. 
-
-Realm types can roughly be classified in two categories:
-
-Internal::  Realms that are internal to Elasticsearch and don't require any
-            communication with external parties. They are fully managed by
-            {security}. There can only be a maximum of one configured realm
-            per internal realm type. {security} provides two internal realm
-            types: `native` and `file`.
-
-External::  Realms that require interaction with parties/components external to
-            {es}, typically, with enterprise grade identity management
-            systems. Unlike internal realms, there can be as many external realms
-            as one would like - each with its own unique name and configuration.
-            {security} provides the following external realm types: `ldap`,
-            `active_directory`, `saml`, and `pki`.

x-pack/docs/en/security/authentication/saml-realm.asciidoc

@@ -1,41 +0,0 @@
-[role="xpack"]
-[[saml-realm]]
-=== SAML authentication
-{security} supports user authentication using SAML Single Sign On.
-{security} provides this support using the Web Browser SSO profile of the SAML
-2.0 protocol.
-
-This protocol is specifically designed to support authentication via an
-interactive web browser, so it does not operate as a standard authentication
-realm. Instead, {security} provides features in {kib} and {es} that work
-together to enable interactive SAML sessions.
-
-This means that the SAML realm is not suitable for use by standard REST clients.
-If you configure a SAML realm for use in {kib}, you should also configure
-another realm, such as the <<native-realm, native realm>> in your authentication
-chain.
-
-In order to simplify the process of configuring SAML authentication within the
-Elastic Stack, there is a step-by-step guide to
-<<saml-guide, Configuring Elasticsearch and Kibana to use SAML Single-Sign-On>>.
-
-The remainder of this document will describe {es} specific configuration options
-for SAML realms.
-
-[[saml-settings]]
-==== SAML realm settings
-
-See {ref}/security-settings.html#ref-saml-settings[SAML Realm Settings]. 
-
-==== SAML realm signing settings
-
-See {ref}/security-settings.html#ref-saml-signing-settings[SAML Realm Signing Settings]. 
-
-==== SAML realm encryption settings
-
-See {ref}/security-settings.html#ref-saml-encryption-settings[SAML Realm Encryption Settings]. 
-
-==== SAML realm SSL settings
-
-See {ref}/security-settings.html#ref-saml-ssl-settings[SAML Realm SSL Settings]. 
-

x-pack/docs/en/security/getting-started.asciidoc

@@ -1,39 +0,0 @@
-[role="xpack"]
-[[security-getting-started]]
-== Getting started with security
-
-To secure a cluster, you must enable {security} on every node in the
-cluster. Basic authentication is enabled by default--to communicate
-with the cluster, you must specify a username and password.
-Unless you {xpack-ref}/anonymous-access.html[enable anonymous access], all
-requests that don't include a user name and password are rejected.
-
-To get started with {security}:
-
-. {ref}/configuring-security.html[Configure security in {es}]. Encrypt 
-inter-node communications, set passwords for the 
-<<built-in-users,built-in users>>, and manage your users and roles.  
-
-. {kibana-ref}/using-kibana-with-security.html[Configure security in {kib}]. 
-Set the authentication credentials in {kib} and encrypt communications between 
-the browser and the {kib} server.
-
-. {logstash-ref}/ls-security.html[Configure security in Logstash]. Set the 
-authentication credentials for Logstash and encrypt communications between 
-Logstash and {es}. 
-
-. <<beats,Configure security in the Beats>>. Configure authentication 
-credentials and encrypt connections to {es}. 
-
-. Configure the Java transport client to use encrypted communications.
-See <<java-clients>>.
-
-. Configure {es} for Apache Hadoop to use secured transport. See
-{hadoop-ref}/security.html[{es} for Apache Hadoop Security]. 
-
-Depending on your security requirements, you might also want to:
-
-* Integrate with {xpack-ref}/ldap-realm.html[LDAP] or {xpack-ref}/active-directory-realm.html[Active Directory],
-or {xpack-ref}/pki-realm.html[require certificates] for authentication.
-* Use {xpack-ref}/ip-filtering.html[IP Filtering] to allow or deny requests from particular
-IP addresses or address ranges.

x-pack/docs/en/security/gs-index.asciidoc

@@ -1,100 +0,0 @@
-[[xpack-security]]
-= Securing Elasticsearch and Kibana
-
-[partintro]
---
-{security} enables you to easily secure a cluster. With Security,
-you can password-protect your data as well as implement more advanced security
-measures such as encrypting communications, role-based access control,
-IP filtering, and auditing. This guide describes how to configure the security
-features you need, and interact with your secured cluster.
-
-Security protects Elasticsearch clusters by:
-
-* <<preventing-unauthorized-access, Preventing unauthorized access>>
-  with password protection, role-based access control, and IP filtering.
-* <<preserving-data-integrity, Preserving the integrity of your data>>
-  with message authentication and SSL/TLS encryption.
-* <<maintaining-audit-trail, Maintaining an audit trail>>
-  so you know who's doing what to your cluster and the data it stores.
-
-[float]
-[[preventing-unauthorized-access]]
-=== Preventing Unauthorized Access
-
-To prevent unauthorized access to your Elasticsearch cluster, you must have a
-way to _authenticate_ users. This simply means that you need a way to validate
-that a user is who they claim to be. For example, you have to make sure only
-the person named _Kelsey Andorra_ can sign in as the user `kandorra`. {security} 
-provides a standalone authentication mechanism that enables you to
-quickly password-protect your cluster. If you're already using {xpack-ref}/ldap-realm.html[LDAP],
-{xpack-ref}/active-directory-realm.html[ Active Directory], or {xpack-ref}/pki-realm.html[ PKI] to manage
-users in your organization, {security} is able to integrate with those
-systems to perform user authentication.
-
-In many cases, simply authenticating users isn't enough. You also need a way to
-control what data users have access to and what tasks they can perform. {security}
-enables you to _authorize_ users by assigning access _privileges_ to _roles_,
-and assigning those roles to users. For example, this
-{xpack-ref}/authorization.html[role-based access control] mechanism (a.k.a RBAC) enables
-you to specify that the user `kandorra` can only perform read operations on the
-`events` index and can't do anything at all with other indices.
-
-{security} also supports {xpack-ref}/ip-filtering.html[ IP-based authorization]. You can
-whitelist and blacklist specific IP addresses or subnets to control network-level
-access to a server.
-
-[float]
-[[preserving-data-integrity]]
-=== Preserving Data Integrity
-
-A critical part of security is keeping confidential data confidential.
-Elasticsearch has built-in protections against accidental data loss and
-corruption. However, there's nothing to stop deliberate tampering or data
-interception. {security} preserves the integrity of your data by
-{xpack-ref}/ssl-tls.html[encrypting communications] to and from nodes and
-{xpack-ref}/enable-message-authentication.html[authenticating message] to verify that they
-have not been tampered with or corrupted in transit during node-to-node
-communication. For even greater protection, you can increase the
-{xpack-ref}/ciphers.html[encryption strength] and
-{xpack-ref}/separating-node-client-traffic.html[separate client traffic from node-to-node communications].
-
-
-[float]
-[[maintaining-audit-trail]]
-=== Maintaining an Audit Trail
-
-Keeping a system secure takes vigilance. By using {security} to maintain
-an audit trail, you can easily see who is accessing your cluster and what they're
-doing. By analyzing access patterns and failed attempts to access your cluster,
-you can gain insights into attempted attacks and data breaches. Keeping an
-auditable log of the activity in your cluster can also help diagnose operational
-issues.
-
-[float]
-=== Where to Go Next
-
-* <<security-getting-started, Getting Started>>
-  steps through how to install and start using Security for basic authentication.
-
-* {xpack-ref}/how-security-works.html[How Security Works]
-  provides more information about how Security supports user authentication,
-  authorization, and encryption.
-
-* {xpack-ref}/ccs-clients-integrations.html[Integrations]
-  shows you how to interact with an Elasticsearch cluster protected by
-  {security}.
-
-* {xpack-ref}/security-reference.html[Reference]
-  provides detailed information about the access privileges you can grant to
-  users, the settings you can configure for Security in `elasticsearch.yml`,
-  and the files where Security configuration information is stored.
-
-[float]
-=== Have Comments, Questions, or Feedback?
-
-Head over to our {security-forum}[Security Discussion Forum]
-to share your experience, questions, and suggestions.
---
-
-include::getting-started.asciidoc[]

x-pack/docs/en/security/how-security-works.asciidoc

@@ -1,98 +0,0 @@
-[role="xpack"]
-[[how-security-works]]
-== How security works
-
-An Elasticsearch cluster is typically made out of many moving parts. There are
-the Elasticsearch nodes that form the cluster, and often Logstash instances,
-Kibana instances, Beats agents an clients, all communicating with the it.
-It should not come as a surprise that securing such clusters has many facets and
-layers.
-
-{security} provides the means to secure the Elastic cluster on several levels:
-
-  * <<setting-up-authentication>>
-  * Authorization and Role Based Access Control (a.k.a RBAC)
-  * Node/Client Authentication and Channel Encryption
-  * Auditing
-
-[float]
-=== Authorization
-
-The authorization process takes place once a request is authenticated and the
-User behind the request is identified. Authorization is the process of determining
-whether the user behind an incoming request is allowed to execute it. Naturally,
-this process takes place right after an successful authentication - when the
-user identity is known.
-
-The authorization process revolves around the following 5 constructs:
-
-_Secured Resource_::
-A resource to which access is restricted. Indices/aliases, documents, fields,
-users and the Elasticsearch cluster itself are all examples of secured objects.
-
-_Privilege_::
-A named group representing one or more actions that a user may execute against a
-secured resource. Each secured resource has its own sets of available privileges.
-For example, `read` is an index privilege that represents all actions that enable
-reading the indexed/stored data. For a complete list of available privileges
-see <<security-privileges>>.
-
-_Permissions_::
-A set of one or more privileges against a secured resource. Permissions can
-easily be described in words, here are few examples:
- * `read` privilege on the `products` index
- * `manage` privilege on the cluster
- * `run_as` privilege on `john` user
- * `read` privilege on documents that match query X
- * `read` privilege on `credit_card` field
-
-_Role_::
-A named sets of permissions
-
-_User_::
-The authenticated user.
-
-A secure Elasticsearch cluster manages the privileges of users through _roles_.
-A role has a unique name and identifies a set of permissions that translate to
-privileges on resources. A user can be associated with an arbitrary number of
-roles. The total set of permissions that a user has is therefore defined by
-union of the permissions in all its roles.
-
-Roles can be assigned to users in a number of ways depending on the realms by
-which the users are authenticated.
-
-For more information on user authentication see <<authorization>>
-
-
-[float]
-=== Node/client authentication and channel encryption
-
-{security} supports configuring SSL/TLS for securing the communication channels
-to, from and within the cluster. This support accounts for:
-
-  * Encryption of data transmitted over the wires
-  * Certificate based node authentication - preventing unauthorized nodes/clients
-    from establishing a connection with the cluster.
-
-For more information, see <<encrypting-communications, Encrypting Communications>>.
-
-{security} also enables you to <<ip-filtering, configure IP Filters>> which can
-be seen as a light mechanism for node/client authentication. With IP Filtering
-you can restrict the nodes and clients that can connect to the cluster based
-on their IP addresses. The IP filters configuration provides whitelisting
-and blacklisting of IPs, subnets and DNS domains.
-
-
-[float]
-=== Auditing
-When dealing with any secure system, it is critical to have a audit trail
-mechanism set in place. Audit trails log various activities/events that occur in
-the system, enabling you to analyze and back track past events when things go
-wrong (e.g. security breach).
-
-{security} provides such audit trail functionality for all nodes in the cluster.
-You can configure the audit level which accounts for the type of events that are
-logged. These events include failed authentication attempts, user access denied,
-node connection denied, and more.
-
-For more information on auditing see <<auditing>>.

x-pack/docs/en/security/index.asciidoc

@@ -1,123 +0,0 @@
-[role="xpack"]
-[[xpack-security]]
-= Securing the {stack}
-
-[partintro]
---
-{security} enables you to easily secure a cluster. With {security},
-you can password-protect your data as well as implement more advanced security
-measures such as encrypting communications, role-based access control,
-IP filtering, and auditing. This guide describes how to configure the security
-features you need, and interact with your secured cluster.
-
-Security protects Elasticsearch clusters by:
-
-* <<preventing-unauthorized-access, Preventing unauthorized access>>
-  with password protection, role-based access control, and IP filtering.
-* <<preserving-data-integrity, Preserving the integrity of your data>>
-  with message authentication and SSL/TLS encryption.
-* <<maintaining-audit-trail, Maintaining an audit trail>>
-  so you know who's doing what to your cluster and the data it stores.
-
-[float]
-[[preventing-unauthorized-access]]
-=== Preventing Unauthorized Access
-
-To prevent unauthorized access to your Elasticsearch cluster, you must have a
-way to _authenticate_ users. This simply means that you need a way to validate
-that a user is who they claim to be. For example, you have to make sure only
-the person named _Kelsey Andorra_ can sign in as the user `kandorra`. {security} 
-provides a standalone authentication mechanism that enables you to
-quickly password-protect your cluster. If you're already using <<ldap-realm, LDAP>>,
-<<active-directory-realm, Active Directory>>, or <<pki-realm, PKI>> to manage
-users in your organization, {security} is able to integrate with those
-systems to perform user authentication.
-
-In many cases, simply authenticating users isn't enough. You also need a way to
-control what data users have access to and what tasks they can perform. {security}
-enables you to _authorize_ users by assigning access _privileges_ to _roles_,
-and assigning those roles to users. For example, this
-<<authorization,role-based access control>> mechanism (a.k.a RBAC) enables
-you to specify that the user `kandorra` can only perform read operations on the
-`events` index and can't do anything at all with other indices.
-
-{security} also supports <<ip-filtering, IP-based authorization>>. You can
-whitelist and blacklist specific IP addresses or subnets to control network-level
-access to a server.
-
-[float]
-[[preserving-data-integrity]]
-=== Preserving Data Integrity
-
-A critical part of security is keeping confidential data confidential.
-Elasticsearch has built-in protections against accidental data loss and
-corruption. However, there's nothing to stop deliberate tampering or data
-interception. {security} preserves the integrity of your data by
-<<ssl-tls, encrypting communications>> to and from nodes.
-For even greater protection, you can increase the <<ciphers, encryption strength>> and
-<<separating-node-client-traffic, separate client traffic from node-to-node communications>>.
-
-
-[float]
-[[maintaining-audit-trail]]
-=== Maintaining an Audit Trail
-
-Keeping a system secure takes vigilance. By using {security} to maintain
-an audit trail, you can easily see who is accessing your cluster and what they're
-doing. By analyzing access patterns and failed attempts to access your cluster,
-you can gain insights into attempted attacks and data breaches. Keeping an
-auditable log of the activity in your cluster can also help diagnose operational
-issues.
-
-[float]
-=== Where to Go Next
-
-* <<security-getting-started, Getting Started>>
-  steps through how to install and start using Security for basic authentication.
-
-* <<how-security-works, How Security Works>>
-  provides more information about how Security supports user authentication,
-  authorization, and encryption.
-
-* <<ccs-clients-integrations>>
-  shows you how to interact with an Elasticsearch cluster protected by
-  {security}.
-
-* <<security-reference, Reference>>
-  provides detailed information about the access privileges you can grant to
-  users, the settings you can configure for Security in `elasticsearch.yml`,
-  and the files where Security configuration information is stored.
-
-[float]
-=== Have Comments, Questions, or Feedback?
-
-Head over to our {security-forum}[Security Discussion Forum]
-to share your experience, questions, and suggestions.
---
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/getting-started.asciidoc
-include::getting-started.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/how-security-works.asciidoc
-include::how-security-works.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authentication/overview.asciidoc
-include::authentication/overview.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/authorization/overview.asciidoc
-include::authorization/overview.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/auditing.asciidoc
-include::auditing/index.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/securing-communications.asciidoc
-include::securing-communications.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/using-ip-filtering.asciidoc
-include::using-ip-filtering.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/ccs-clients-integrations.asciidoc
-include::ccs-clients-integrations.asciidoc[]
-
-:edit_url: https://github.com/elastic/elasticsearch/edit/{branch}/x-pack/docs/en/security/reference.asciidoc
-include::reference.asciidoc[]