realms.asciidoc 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475
  1. [role="xpack"]
  2. [[realms]]
  3. === Realms
  4. The {stack-security-features} authenticate users by using realms and one or more
  5. <<token-authentication-services,token-based authentication services>>.
  6. A _realm_ is used to resolve and authenticate users based on authentication
  7. tokens. The {security-features} provide the following built-in realms:
  8. _native_::
  9. An internal realm where users are stored in a dedicated {es} index.
  10. This realm supports an authentication token in the form of username and password,
  11. and is available by default when no realms are explicitly configured. The users
  12. are managed via the <<security-user-apis,user management APIs>>.
  13. See <<native-realm>>.
  14. _ldap_::
  15. A realm that uses an external LDAP server to authenticate the
  16. users. This realm supports an authentication token in the form of username and
  17. password, and requires explicit configuration in order to be used. See
  18. <<ldap-realm>>.
  19. _active_directory_::
  20. A realm that uses an external Active Directory Server to authenticate the
  21. users. With this realm, users are authenticated by usernames and passwords.
  22. See <<active-directory-realm>>.
  23. _pki_::
  24. A realm that authenticates users using Public Key Infrastructure (PKI). This
  25. realm works in conjunction with SSL/TLS and identifies the users through the
  26. Distinguished Name (DN) of the client's X.509 certificates. See <<pki-realm>>.
  27. _file_::
  28. An internal realm where users are defined in files stored on each node in the
  29. {es} cluster. This realm supports an authentication token in the form
  30. of username and password and is always available. See <<file-realm>>.
  31. _saml_::
  32. A realm that facilitates authentication using the SAML 2.0 Web SSO protocol.
  33. This realm is designed to support authentication through {kib} and is not
  34. intended for use in the REST API. See <<saml-realm>>.
  35. _kerberos_::
  36. A realm that authenticates a user using Kerberos authentication. Users are
  37. authenticated on the basis of Kerberos tickets. See <<kerberos-realm>>.
  38. _oidc_::
  39. A realm that facilitates authentication using OpenID Connect. It enables {es} to serve as an OpenID Connect Relying Party (RP) and provide single sign-on (SSO) support in {kib}. See <<oidc-guide>>.
  40. _jwt_::
  41. A realm that facilitates using JWT identity tokens as authentication bearer tokens.
  42. Compatible tokens are OpenID Connect ID Tokens, or custom JWTs containing the same claims.
  43. See <<jwt-auth-realm>>.
  44. The {security-features} also support custom realms. If you need to integrate
  45. with another authentication system, you can build a custom realm plugin. For
  46. more information, see <<custom-realms>>.
  47. ==== Internal and external realms
  48. Realm types can roughly be classified in two categories:
  49. Internal:: Realms that are internal to Elasticsearch and don't require any
  50. communication with external parties. They are fully managed by the {stack}
  51. {security-features}. There can only be a maximum of one configured realm per
  52. internal realm type. The {security-features} provide two internal realm
  53. types: `native` and `file`.
  54. External:: Realms that require interaction with parties/components external to
  55. {es}, typically, with enterprise grade identity management systems. Unlike
  56. internal realms, there can be as many external realms as one would like - each
  57. with its own unique name and configuration. The {security-features} provide the
  58. following external realm types: `ldap`, `active_directory`, `saml`, `kerberos`,
  59. and `pki`.