user-profile.asciidoc 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102
  1. [role="xpack"]
  2. [[user-profile]]
  3. === User profiles
  4. NOTE: The user profile feature is designed only for use by {kib} and
  5. Elastic’s {observability}, {ents}, and {elastic-sec} solutions. Individual
  6. users and external applications should not call this API directly. Elastic reserves
  7. the right to change or remove this feature in future releases without prior notice.
  8. Because the {stack} supports externally-managed users (such as users who
  9. authenticate via SAML, or users stored in an LDAP directory), there's a
  10. distinction between _users_ and their _profile_.
  11. _Users_ refer to the entities that authenticate requests to the {stack}.
  12. Each user has a username and a set of privileges (represented by <<roles,roles>>)
  13. that determine which types of requests they can issue. Users can be ephemeral;
  14. they might exist only for the duration of a request to an {es} API or for the
  15. lifetime of a session in {kib}. These users cannot be retrieved after the session
  16. ends, and can't store preferences across sessions.
  17. _User profiles_ provide persistent and stable representations of users.
  18. A user profile exists even if the user is offline, so their profile persists across sessions.
  19. The unique identifier assigned to each profile doesn't change
  20. throughout the lifetime of a deployment, providing a stable way of referring
  21. to the associated user. Each profile has a unique identifier, is searchable, and
  22. can store user data such as format and notification preferences.
  23. The capability of uniquely referring to users regardless of whether they're
  24. actively online is a critical function that underpins important features like
  25. personalization and collaboration in {kib}.
  26. ==== User profiles in {kib}
  27. A user profile is the persistent record that the {stack} stores for each
  28. interactive user that authenticates to {kib}.
  29. When a user logs in to {kib}, a profile is automatically created for the user,
  30. or an existing profile is updated to reflect the user's active session.
  31. By using the unique ID of the user profile, {kib} can store user-level data such as preferences
  32. separately for each user, which is key to fine-grained levels of customization.
  33. {kib} uses this unique ID to route messages and notifications to a distinct user,
  34. regardless of whether they're logged in.
  35. ===== Usernames and user profiles
  36. You can use the same username across multiple realms for a single user. In {es},
  37. it's possible for two different realms to authenticate users with the same username
  38. and different roles.
  39. {es} doesn't assume that these users are the same person, and treats
  40. them as separate individuals with distinct user profiles by default.
  41. NOTE: For use cases where one individual can authenticate against
  42. multiple realms, you can use the <<security-domain,security domain>> feature
  43. so that these distinct users are considered to be the same identity
  44. and share a single user profile.
  45. ==== Create and manage user profiles
  46. To create a new user profile or update an existing one, use the
  47. <<security-api-activate-user-profile,activate user profile API>>. When you
  48. submit a request, {es} attempts to locate an existing profile document for the
  49. specified user. If one doesn't exist, {es} creates a new profile document.
  50. In either case, the profile document captures the user's `full_name`, `email`,
  51. `roles`, and `realms`, and also includes the profile unique ID and timestamp of
  52. the operation. You can retrieve a user profile with
  53. the <<security-api-get-user-profile,get user profile API>> by including the
  54. profile's unique ID (`uid`).
  55. In addition to the user's basic information, you can add data to a profile document
  56. with the <<security-api-update-user-profile-data,update user profile API>>. For
  57. example, you can add user-specific preferences as part of the profile data.
  58. Use the <<security-api-suggest-user-profile,suggest user profile API>> to retrieve profiles
  59. that match given criteria. This API is designed to support user-suggestions,
  60. in collaboration with features such as those found in {kib}.
  61. However, the suggest user profile API is not intended to provide a general-purpose search API.
  62. Lastly, you can use the <<security-api-has-privileges-user-profile, has privileges API for
  63. user profiles>> to check the privileges of multiple users by specifying their profiles' unique IDs.
  64. This can be used in conjunction with the suggest user profile API in order to restrict the
  65. suggestions only to users that have the necessary permissions to actually perform
  66. the action in the context.
  67. ==== Limitations
  68. * Creating a new user profile requires a user's authentication details
  69. (`username` and `password` or its
  70. <<token-authentication-services,OAuth2 access token>>).
  71. This means that a user must authenticate at least one time to create a
  72. user profile. Users who have never authenticated to {kib}
  73. (or another profile-aware application) won't have a user profile, and the
  74. <<security-api-suggest-user-profile,suggest user profile API>> won't return
  75. any results for those users.
  76. * User profiles are meant for interactive users, such as a human user who
  77. interacts with {kib}. Therefore, user profiles don't support API keys or
  78. <<service-accounts,service accounts>>.
  79. +
  80. NOTE: <<token-authentication-services,OAuth2 tokens>> that represent an
  81. interactive end-user are supported.