role-templates.asciidoc 2.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. [[templating-role-query]]
  2. ==== Templating a role query
  3. When you create a role, you can specify a query that defines the
  4. <<document-level-security,document level security permissions>>. You can
  5. optionally use Mustache templates in the role query to insert the username of the
  6. current authenticated user into the role. Like other places in {es} that support
  7. templating or scripting, you can specify inline, stored, or file-based templates
  8. and define custom parameters. You access the details for the current
  9. authenticated user through the `_user` parameter.
  10. For example, the following role query uses a template to insert the username
  11. of the current authenticated user:
  12. [source,console]
  13. --------------------------------------------------
  14. POST /_security/role/example1
  15. {
  16. "indices" : [
  17. {
  18. "names" : [ "my-index-000001" ],
  19. "privileges" : [ "read" ],
  20. "query" : {
  21. "template" : {
  22. "source" : {
  23. "term" : { "acl.username" : "{{_user.username}}" }
  24. }
  25. }
  26. }
  27. }
  28. ]
  29. }
  30. --------------------------------------------------
  31. You can access the following information through the `_user` variable:
  32. [options="header"]
  33. |======
  34. | Property | Description
  35. | `_user.username` | The username of the current authenticated user.
  36. | `_user.full_name` | If specified, the full name of the current authenticated user.
  37. | `_user.email` | If specified, the email of the current authenticated user.
  38. | `_user.roles` | If associated, a list of the role names of the current authenticated user.
  39. | `_user.metadata` | If specified, a hash holding custom metadata of the current authenticated user.
  40. |======
  41. You can also access custom user metadata. For example, if you maintain a
  42. `group_id` in your user metadata, you can apply document level security
  43. based on the `group.id` field in your documents:
  44. [source,console]
  45. --------------------------------------------------
  46. POST /_security/role/example2
  47. {
  48. "indices" : [
  49. {
  50. "names" : [ "my-index-000001" ],
  51. "privileges" : [ "read" ],
  52. "query" : {
  53. "template" : {
  54. "source" : {
  55. "term" : { "group.id" : "{{_user.metadata.group_id}}" }
  56. }
  57. }
  58. }
  59. }
  60. ]
  61. }
  62. --------------------------------------------------
  63. If your metadata field contains an object or array, you can access it using the
  64. `{{#toJson}}parameter{{/toJson}}` function.
  65. [source,console]
  66. ----
  67. POST /_security/role/example3
  68. {
  69. "indices" : [
  70. {
  71. "names" : [ "my-index-000001" ],
  72. "privileges" : [ "read" ],
  73. "query" : {
  74. "template" : {
  75. "source" : "{ \"terms\": { \"group.statuses\": {{#toJson}}_user.metadata.statuses{{/toJson}} }}"
  76. }
  77. }
  78. }
  79. ]
  80. }
  81. ----