anchor.diff:  [[set-security-user-processor]]
   ===== Set Security User Ingest Processor
   
  -If an index is being shared by many small users it makes sense put all these users into the same index as having a
  -dedicated index or shard per user is too wasteful. In order to guarantee that a user only read its own documents it
  -makes sense to set up document level security. In order to use document level security for this each document must have
  -the username or role name associated with it, so that it can be queried by the document level security's role query.
  -This is where the `set_security_user` ingest processor can help.
  -
  -NOTE: You need to make sure to use unique ids for each user that uses the same index, because document level security
  -      doesn't apply on write APIs and you can overwrite other users' documents. This ingest processor just adds
  -      properties of the current authenticated user to the documents being indexed.
  -
  -
  -The `set_security_user` processor attaches user related details (`username`, `roles`, `email`, `full_name` and `metadata` )
  -from the current authenticated user to the current document by pre-processed by ingest.
  -
  -So when indexing data with an ingest pipeline then user details get automatically attached with the document:
  +If an index is shared by many small users it makes sense to put all these users
  +into the same index.  Having a dedicated index or shard per user is wasteful.
  +To guarantee that a user reads only their own documents, it makes sense to set up
  +document level security. In this scenario, each document must have the username
  +or role name associated with it, so that this information can be used by the
  +role query for document level security. This is a situation where the
  +`set_security_user` ingest processor can help.
  +
  +NOTE: Document level security doesn't apply to write APIs. You must use unique
  +ids for each user that uses the same index, otherwise they might overwrite other
  +users' documents. The ingest processor just adds properties for the current
  +authenticated user to the documents that are being indexed.
  +
  +The `set_security_user` processor attaches user-related details (such as
  +`username`,  `roles`, `email`, `full_name` and `metadata` ) from the current
  +authenticated user to the current document by pre-processing the ingest. When
  +you index data with an ingest pipeline, user details are automatically attached
  +to the document. For example:
   
   [source,js]
   --------------------------------------------------
  
positive.code: ==== Multiple Roles with Document and Field Level Security
  
  A user can have many roles and each role can define different permissions on the
  same index. It is important to understand the behavior of Document and Field Level
  security in this scenario.
  
  Document level security will take into account each role held by the user, and
  combine each document level security query for a given index with an "OR". This
  means that only one of the role queries must match for a document to be returned.
  For example, if a role grants access to an index without document level security
  and another grants access with document level security, document level security
  will not be applied; the user with both roles will have access to all of the
  documents in the index.
  
  Field level security will take into account each role the user has and combine
  all of the fields listed into a single set for each index. For example, if a
  role grants access to an index without field level security and another grants
  access with field level security, field level security will not be applied for
  that index; the user with both roles will have access to all of the fields in
  in the index.
  
negative.code: }
  --------------------------------------------------
  
  The following role definition enables only read access to the customer `handle`
  field:
  
  [source,js]
  --------------------------------------------------
  