# Document Level Security Based On External Data
**URL:** https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537
**Category:** Elasticsearch
**Tags:** elastic-stack-security
**Created:** [November 13, 2018, 7:55pm UTC](https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537 "2018-11-13T19:55:42Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@kmontagne](https://discuss.elastic.co/u/kmontagne)
#### Post date: [November 13, 2018, 7:55pm UTC](https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537/1 "2018-11-13T19:55:42Z")
I have a use case where I need to restrict access to documents in an Elasticsearch index based on the user executing the query and one of the attributes in the document. The catch is that this is dynamic and the logic to determine if a user can see a specific document is a bit convoluted and based on data in an external database. Conceptually it would be nice if I could have a dynamic filter (e.g. plugin) configured in Elasticsearch that would take as input the connected user and the document (or a subset of its fields) and return a boolean indicating whether the document should be returned to the user.
Does such a solution exist in Elasticsearch or any third party products?
---
### Author:  [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [November 13, 2018, 8:04pm UTC](https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537/2 "2018-11-13T20:04:58Z")
Calling out to an external system per user and document sounds extremely slow and I do not recall seeing any solutions that allow this.
Elasticsearch security does however support document-level security, both based on roles as well as attributes, so it might be possible to build something that matches what is in your external system. Have a look at the following blog posts for some examples:
> **[Securing GDPR Personal Data with Access Controls
| Elastic](https://www.elastic.co/blog/securing-gdpr-personal-data-with-access-controls)**
>
> As described in our GDPR white paper, preventing unauthorized access to personal data is a key requirement of GDPR. In this post, we will provide an overview of Elasticsearch security features (powere...
> **[Document-Level Attribute-Based Access Control with X-Pack 6.1
| Elastic](https://www.elastic.co/blog/attribute-based-access-control-with-xpack)**
>
> Thanks to a new feature in Lucene 7.1, the CoveringQuery, and the exposure of that feature in the new terms\_set query released with Elasticsearch 6.1, it is possible to setup an attribute-ba...
---
### Author:  [@kmontagne](https://discuss.elastic.co/u/kmontagne)
#### Post date: [November 13, 2018, 9:04pm UTC](https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537/3 "2018-11-13T21:04:29Z")
Christian thanks for the reply. I will take a look at those posts.
A callout does not have to be slow. If implemented as a plugin on the server and the plugin implemented some type of smart computational cache then it could only be a few extra lines of Java executed when there was a cache hit. For example the cache entry could be a set of allowed values of the attribute(s) that is computed on the first document that a user searches for rather than for every document in a search. It could also save that cache entry between searches and since the underlying model in my case is dynamic it could refresh it if it passed some expiration time. Again this refresh would be done only for the first document in the new search.
---
### Author:  [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [November 13, 2018, 9:17pm UTC](https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537/4 "2018-11-13T21:17:46Z")
If it is going to be fast I suspect a custom plugin will be required.
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [December 11, 2018, 9:17pm UTC](https://discuss.elastic.co/t/document-level-security-based-on-external-data/156537/5 "2018-12-11T21:17:48Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.