# Extend Elasticsearch Authorization mechanism to existing instances **URL:** \ **Category:** Elasticsearch\ **Tags:** elastic-stack-security\ **Created:** [December 3, 2018, 3:33pm UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205 "2018-12-03T15:33:46Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Uiidoi12](https://avatars.discourse-cdn.com/v4/letter/u/73ab20/32.png) [@Uiidoi12](https://discuss.elastic.co/u/Uiidoi12)\ **Post date:** [December 3, 2018, 3:33pm UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/1 "2018-12-03T15:33:46Z")
Hi, I have a situation where there are existing Elasticsearch instances that uses X-Pack security and need to extend **Authorization** mechanism in order to change the default behaviour and contact an external service to obtain a list of authorizations (I still need to decide what kind of data to return) so that I will use those authorizations to allow or deny user requests or retrieve only a specific set of data according to a specific filter coming from the authorizations list. What do you think are my options for something like that? Do I need to do creating a security extension like it was done [in this official blog post](https://www.elastic.co/blog/how-to-develop-your-own-security-extensions-and-custom-realms-for-elasticsearch)? Any other idea or advice? Thanks a lot! ---
**Author:** ![Yogesh\_Gaikwad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/yogesh_gaikwad/32/27025_2.png) [@Yogesh\_Gaikwad](https://discuss.elastic.co/u/Yogesh_Gaikwad)\ **Post date:** [December 4, 2018, 3:17am UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/2 "2018-12-04T03:17:24Z")
Hi @Uiidoi12, From your problem description, it seems like you want to do authorization based on some data fetched from an external system. As you have not mentioned what data will look like or what authorization controls you want it is hard to give possible solutions. With version 6.5 you have an option of authorization realm which can then fetch data from your external system, [https://www.elastic.co/guide/en/elastic-stack-overview/master/realm-chains.html#authorization\_realms](https://www.elastic.co/guide/en/elastic-stack-overview/master/realm-chains.html#authorization_realms) [Future] For customizable authorization, we have an issue open which is under consideration but we do not have any timelines or what it would look like: > Hope this helps Thanks and Regards, Yogesh Gaikwad ---
**Author:** ![Uiidoi12](https://avatars.discourse-cdn.com/v4/letter/u/73ab20/32.png) [@Uiidoi12](https://discuss.elastic.co/u/Uiidoi12)\ **Post date:** [December 4, 2018, 8:58am UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/3 "2018-12-04T08:58:07Z")
Hi @Yogesh_Gaikwad and thank you for your answer! I actually have also requirements for the Elasticsearch version, it is 6.2 and so I also have more limitations as far as I understood. About the type of authorization controls, a possible scenario of what I need is the following: 1. a user with id "johndoe" asks to retrieve all existing fruits from an Elasticsearch instance 2. then, Elasticsearch authorization mechanism will ask an external service to retrieve the list of authorizations for the user "johndoe" 3. at this point, the search on Elasticsearch will be executed but it won't be "retrieve all fruits", but it will be "retrieve all fruits that user 'johndoe' is authorized to see" (e.g. "retrieve all red colored fruits") any way to implement something like this on Elasticsearch 6.2 (or 6.5 in case I will have the chance to work with that new version)? Thanks ---
**Author:** ![Uiidoi12](https://avatars.discourse-cdn.com/v4/letter/u/73ab20/32.png) [@Uiidoi12](https://discuss.elastic.co/u/Uiidoi12)\ **Post date:** [December 12, 2018, 10:30am UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/4 "2018-12-12T10:30:12Z")
Hi, any idea about how I can implement something like that? Regads, Thanks ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [December 12, 2018, 10:59am UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/5 "2018-12-12T10:59:21Z")
You may want to look into combining custom authentication with attribute-based access controls. Not sure whether this would fit your needs or not, but you can find a bit more information in these blogs: > **[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:** ![Uiidoi12](https://avatars.discourse-cdn.com/v4/letter/u/73ab20/32.png) [@Uiidoi12](https://discuss.elastic.co/u/Uiidoi12)\ **Post date:** [December 12, 2018, 11:28am UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/6 "2018-12-12T11:28:59Z")
Thanks @Christian_Dahlqvist I'll check them. One question: do I need premium X-Pack to use "Attribute-based access controls"? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [December 12, 2018, 11:45am UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/7 "2018-12-12T11:45:47Z")
Yes, the document and field level security used in these blog posts are a Platinum level feature. ---
**Author:** ![Uiidoi12](https://avatars.discourse-cdn.com/v4/letter/u/73ab20/32.png) [@Uiidoi12](https://discuss.elastic.co/u/Uiidoi12)\ **Post date:** [December 12, 2018, 2:13pm UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/8 "2018-12-12T14:13:57Z")
@Christian_Dahlqvist thanks. Any other way to do that without using Platinum X-Pack features? Thanks **edit** : alternatively, would it be possible to build a plugin to catch all requests toward Elasticsearch so that I will be able to edit them and add some kind of filtering before sending them? ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [December 12, 2018, 2:33pm UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/9 "2018-12-12T14:33:38Z")
I believe all our commercial features are technically built as plugins, so I am reasonably sure it is possible. I do however not think it necessarily is easy and would expect it to require a good amount of effort. On top of that you also need to factor in the effort required to maintain and upgrade it. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [January 9, 2019, 2:33pm UTC](https://discuss.elastic.co/t/extend-elasticsearch-authorization-mechanism-to-existing-instances/159205/10 "2019-01-09T14:33:39Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.