# Creating an OAuth2 Plugin? **URL:** \ **Category:** Elasticsearch\ **Created:** [April 10, 2013, 8:30pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537 "2013-04-10T20:30:38Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Chris\_Berry\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chris_berry_2/32/1366_2.png) [@Chris\_Berry\_2](https://discuss.elastic.co/u/Chris_Berry_2)\ **Post date:** [April 10, 2013, 8:30pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/1 "2013-04-10T20:30:38Z")
Greetings, We are in the process of building out an Elasticsearch cluster, and we need security. (it's too easy to do scary things to the cluster) Currently we use OAuth2 for Service-to-service security in our SOA (although only 2-legged instead of 3). And we need to add this functionality for elasticsearch. We understand that we can pretty easily secure the HTTP port (9200) -- teh jetty plugin, etc. But we will be using the TCP port (9300), and need to secure it as well (or it defeats the purpose). First, obviously -- has anyone out there already done this?? And if so, is the code out there in the wild... Second, my goggling says that we'll probably need to build this ourselves. Is creating/wiring in a Transport Plugin the correct approach?? Thanks, -- Chris -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [April 10, 2013, 9:58pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/2 "2013-04-10T21:58:33Z")
The transport port range (9300-9399) is for internal cluster use. Note there may be more ports, for example, if you install transport plugins. If you put your whole cluster into a private network - see [Private network - Wikipedia](http://en.wikipedia.org/wiki/Private_network) - you can control access to ES just by adding your favorite proxy/router/firewall in front of it. Jörg Am 10.04.13 22:30, schrieb Chris Berry: > Greetings, > > We are in the process of building out an Elasticsearch cluster, and we > need security. (it's too easy to do scary things to the cluster) > Currently we use OAuth2 for Service-to-service security in our SOA > (although only 2-legged instead of 3). > And we need to add this functionality for elasticsearch. > > We understand that we can pretty easily secure the HTTP port (9200) -- > teh jetty plugin, etc. > But we will be using the TCP port (9300), and need to secure it as > well (or it defeats the purpose). > > First, obviously -- has anyone out there already done this?? And if > so, is the code out there in the wild... > > Second, my goggling says that we'll probably need to build this ourselves. > Is creating/wiring in a Transport Plugin the correct approach?? > > Thanks, > -- Chris -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![egaumer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/egaumer/32/2365_2.png) [@egaumer](https://discuss.elastic.co/u/egaumer)\ **Post date:** [April 10, 2013, 10:22pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/3 "2013-04-10T22:22:30Z")
We built an OAuth2 layer with full index level ACL support on top of elasticsearch (opposed to using the plugin architecture). This allows us to control every aspect and elasticsearch embeds really well. We restrict access to the transport though so you have to use HTTPS (no TCP). We support SPDY and use an embedded instance of Jetty with async servlets (to support Spring Security). -Eric On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > Greetings, > > We are in the process of building out an Elasticsearch cluster, and we > need security. (it's too easy to do scary things to the cluster) > Currently we use OAuth2 for Service-to-service security in our SOA > (although only 2-legged instead of 3). > And we need to add this functionality for elasticsearch. > > We understand that we can pretty easily secure the HTTP port (9200) -- teh > jetty plugin, etc. > But we will be using the TCP port (9300), and need to secure it as well > (or it defeats the purpose). > > First, obviously -- has anyone out there already done this?? And if so, is > the code out there in the wild... > > Second, my goggling says that we'll probably need to build this ourselves. > Is creating/wiring in a Transport Plugin the correct approach?? > > Thanks, > -- Chris -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![roytmana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/roytmana/32/44855_2.png) [@roytmana](https://discuss.elastic.co/u/roytmana)\ **Post date:** [April 12, 2013, 1:28pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/4 "2013-04-12T13:28:46Z")
Eric, Could you elaborate a bit. You say you embed elastic rather than using plugin strategy. Do you run it within a servlet container and replicate complete API with your ACL checks before making the same elastic call? Do you call elastic via java API or pass http request on to elastic http endpoint. Also you said you use embedded jetty. I am confused a bit what's embedded in what - elastic or jetty? Thanks, Alex On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > We built an OAuth2 layer with full index level ACL support on top of > elasticsearch (opposed to using the plugin architecture). This allows us to > control every aspect and elasticsearch embeds really well. We restrict > access to the transport though so you have to use HTTPS (no TCP). We > support SPDY and use an embedded instance of Jetty with async servlets (to > support Spring Security). > > -Eric > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > Greetings, > > > > We are in the process of building out an Elasticsearch cluster, and we > > need security. (it's too easy to do scary things to the cluster) > > Currently we use OAuth2 for Service-to-service security in our SOA > > (although only 2-legged instead of 3). > > And we need to add this functionality for elasticsearch. > > > > We understand that we can pretty easily secure the HTTP port (9200) -- > > teh jetty plugin, etc. > > But we will be using the TCP port (9300), and need to secure it as well > > (or it defeats the purpose). > > > > First, obviously -- has anyone out there already done this?? And if so, > > is the code out there in the wild... > > > > Second, my goggling says that we'll probably need to build this ourselves. > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > Thanks, > > -- Chris -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![egaumer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/egaumer/32/2365_2.png) [@egaumer](https://discuss.elastic.co/u/egaumer)\ **Post date:** [April 13, 2013, 1:57am UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/5 "2013-04-13T01:57:42Z")
We run inside a servlet container by implementing our own RestChannel. [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java) This lets us intercept every call and run custom security logic before handing it off to elasticsearch and we don't have to reimplement every endpoint via the Java API. In terms of Jetty, what I mean is that we don't produce a WAR, rather we embed an instance of Jetty inside the app. So we embed elasticsearch inside our app along side of Jetty. We debated of over using servlets but we decided Spring Security was worth it. We're using Servlet 3.0 (async) and we're happy with the choice because it gives us a lot of capability. -Eric On Friday, April 12, 2013 9:28:46 AM UTC-4, AlexR wrote: > Eric, > > Could you elaborate a bit. You say you embed elastic rather than using > plugin strategy. Do you run it within a servlet container and replicate > complete API with your ACL checks before making the same elastic call? Do > you call elastic via java API or pass http request on to elastic http > endpoint. Also you said you use embedded jetty. I am confused a bit what's > embedded in what - elastic or jetty? > > Thanks, > Alex > > On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > > > We built an OAuth2 layer with full index level ACL support on top of > > elasticsearch (opposed to using the plugin architecture). This allows us to > > control every aspect and elasticsearch embeds really well. We restrict > > access to the transport though so you have to use HTTPS (no TCP). We > > support SPDY and use an embedded instance of Jetty with async servlets (to > > support Spring Security). > > > > -Eric > > > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > > > Greetings, > > > > > > We are in the process of building out an Elasticsearch cluster, and we > > > need security. (it's too easy to do scary things to the cluster) > > > Currently we use OAuth2 for Service-to-service security in our SOA > > > (although only 2-legged instead of 3). > > > And we need to add this functionality for elasticsearch. > > > > > > We understand that we can pretty easily secure the HTTP port (9200) -- > > > teh jetty plugin, etc. > > > But we will be using the TCP port (9300), and need to secure it as well > > > (or it defeats the purpose). > > > > > > First, obviously -- has anyone out there already done this?? And if so, > > > is the code out there in the wild... > > > > > > Second, my goggling says that we'll probably need to build this > > > ourselves. > > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > > > Thanks, > > > -- Chris -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![roytmana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/roytmana/32/44855_2.png) [@roytmana](https://discuss.elastic.co/u/roytmana)\ **Post date:** [April 16, 2013, 5:24pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/6 "2013-04-16T17:24:44Z")
Thanks Eric for the tip! It is likely we will need to go this route in the future. Do you hide all your cluster behind a firewall so nodes (or ingesting servers/nodes if any) can communicate via IP safely and only expose your protected endpoint to consuming applications? If you have just one "public" endpoint what happens if that node fails. Or it is not an issue because this node IS your application. so if it is down both the node and your app are down... Thanks, Alex On Friday, April 12, 2013 9:57:42 PM UTC-4, egaumer wrote: > We run inside a servlet container by implementing our own RestChannel. > > [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java) > > This lets us intercept every call and run custom security logic before > handing it off to elasticsearch and we don't have to reimplement every > endpoint via the Java API. > > In terms of Jetty, what I mean is that we don't produce a WAR, rather we > embed an instance of Jetty inside the app. So we embed elasticsearch inside > our app along side of Jetty. We debated of over using servlets but we > decided Spring Security was worth it. We're using Servlet 3.0 (async) and > we're happy with the choice because it gives us a lot of capability. > > -Eric > > On Friday, April 12, 2013 9:28:46 AM UTC-4, AlexR wrote: > > > Eric, > > > > Could you elaborate a bit. You say you embed elastic rather than using > > plugin strategy. Do you run it within a servlet container and replicate > > complete API with your ACL checks before making the same elastic call? Do > > you call elastic via java API or pass http request on to elastic http > > endpoint. Also you said you use embedded jetty. I am confused a bit what's > > embedded in what - elastic or jetty? > > > > Thanks, > > Alex > > > > On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > > > > > We built an OAuth2 layer with full index level ACL support on top of > > > elasticsearch (opposed to using the plugin architecture). This allows us to > > > control every aspect and elasticsearch embeds really well. We restrict > > > access to the transport though so you have to use HTTPS (no TCP). We > > > support SPDY and use an embedded instance of Jetty with async servlets (to > > > support Spring Security). > > > > > > -Eric > > > > > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > > > > > Greetings, > > > > > > > > We are in the process of building out an Elasticsearch cluster, and we > > > > need security. (it's too easy to do scary things to the cluster) > > > > Currently we use OAuth2 for Service-to-service security in our SOA > > > > (although only 2-legged instead of 3). > > > > And we need to add this functionality for elasticsearch. > > > > > > > > We understand that we can pretty easily secure the HTTP port (9200) -- > > > > teh jetty plugin, etc. > > > > But we will be using the TCP port (9300), and need to secure it as well > > > > (or it defeats the purpose). > > > > > > > > First, obviously -- has anyone out there already done this?? And if so, > > > > is the code out there in the wild... > > > > > > > > Second, my goggling says that we'll probably need to build this > > > > ourselves. > > > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > > > > > Thanks, > > > > -- Chris -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mattweber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mattweber/32/44940_2.png) [@mattweber](https://discuss.elastic.co/u/mattweber)\ **Post date:** [April 17, 2013, 9:36pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/7 "2013-04-17T21:36:55Z")
Hey Alex, Any node in our cluster could be the "public" endpoint so we typically just have a load balancer pick one of the nodes. The transport ports (9300, etc) are all blocked by firewall rules (except from internal network) and the http server (9200) is completely disabled since we only allow access though our secure servlet. Thanks, Matt Weber On Tue, Apr 16, 2013 at 10:24 AM, AlexR [roytmana@gmail.com](mailto:roytmana@gmail.com) wrote: > Thanks Eric for the tip! > > It is likely we will need to go this route in the future. Do you hide all > your cluster behind a firewall so nodes (or ingesting servers/nodes if any) > can communicate via IP safely and only expose your protected endpoint to > consuming applications? If you have just one "public" endpoint what happens > if that node fails. Or it is not an issue because this node IS your > application. so if it is down both the node and your app are down... > > Thanks, > Alex > > On Friday, April 12, 2013 9:57:42 PM UTC-4, egaumer wrote: > > > We run inside a servlet container by implementing our own RestChannel. > > > > [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java) > > > > This lets us intercept every call and run custom security logic before > > handing it off to elasticsearch and we don't have to reimplement every > > endpoint via the Java API. > > > > In terms of Jetty, what I mean is that we don't produce a WAR, rather we > > embed an instance of Jetty inside the app. So we embed elasticsearch inside > > our app along side of Jetty. We debated of over using servlets but we > > decided Spring Security was worth it. We're using Servlet 3.0 (async) and > > we're happy with the choice because it gives us a lot of capability. > > > > -Eric > > > > On Friday, April 12, 2013 9:28:46 AM UTC-4, AlexR wrote: > > > > > Eric, > > > > > > Could you elaborate a bit. You say you embed elastic rather than using > > > plugin strategy. Do you run it within a servlet container and replicate > > > complete API with your ACL checks before making the same elastic call? Do > > > you call elastic via java API or pass http request on to elastic http > > > endpoint. Also you said you use embedded jetty. I am confused a bit what's > > > embedded in what - elastic or jetty? > > > > > > Thanks, > > > Alex > > > > > > On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > > > > > > > We built an OAuth2 layer with full index level ACL support on top of > > > > elasticsearch (opposed to using the plugin architecture). This allows us to > > > > control every aspect and elasticsearch embeds really well. We restrict > > > > access to the transport though so you have to use HTTPS (no TCP). We support > > > > SPDY and use an embedded instance of Jetty with async servlets (to support > > > > Spring Security). > > > > > > > > -Eric > > > > > > > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > > > > > > > Greetings, > > > > > > > > > > We are in the process of building out an Elasticsearch cluster, and we > > > > > need security. (it's too easy to do scary things to the cluster) > > > > > Currently we use OAuth2 for Service-to-service security in our SOA > > > > > (although only 2-legged instead of 3). > > > > > And we need to add this functionality for elasticsearch. > > > > > > > > > > We understand that we can pretty easily secure the HTTP port (9200) -- > > > > > teh jetty plugin, etc. > > > > > But we will be using the TCP port (9300), and need to secure it as well > > > > > (or it defeats the purpose). > > > > > > > > > > First, obviously -- has anyone out there already done this?? And if so, > > > > > is the code out there in the wild... > > > > > > > > > > Second, my goggling says that we'll probably need to build this > > > > > ourselves. > > > > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > > > > > > > Thanks, > > > > > -- Chris > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![roytmana](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/roytmana/32/44855_2.png) [@roytmana](https://discuss.elastic.co/u/roytmana)\ **Post date:** [April 17, 2013, 10:24pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/8 "2013-04-17T22:24:59Z")
I see Matt thanks it makes sense. I wish I could pick your brain on RestChannel if we had to go this route (our first phase does not require any index or document level ACL just deny update/admin functionality to the REST client which I do with apache mod\_proxy for now. It would be nice if ES had a security or at least an interceptor framework allowing to register specialized plugins rather than doing it on transport level like jetty plugin (or your rest channel implementation if it is much different) On Wednesday, April 17, 2013 5:36:55 PM UTC-4, Matt Weber wrote: > Hey Alex, > > Any node in our cluster could be the "public" endpoint so we typically > just have a load balancer pick one of the nodes. The transport ports > (9300, etc) are all blocked by firewall rules (except from internal > network) and the http server (9200) is completely disabled since we > only allow access though our secure servlet. > > Thanks, > Matt Weber > > On Tue, Apr 16, 2013 at 10:24 AM, AlexR \<[royt...@gmail.com](mailto:royt...@gmail.com) \\> > wrote: > > > Thanks Eric for the tip! > > > > It is likely we will need to go this route in the future. Do you hide > > all > > your cluster behind a firewall so nodes (or ingesting servers/nodes if > > any) > > can communicate via IP safely and only expose your protected endpoint to > > consuming applications? If you have just one "public" endpoint what > > happens > > if that node fails. Or it is not an issue because this node IS your > > application. so if it is down both the node and your app are down... > > > > Thanks, > > Alex > > > > On Friday, April 12, 2013 9:57:42 PM UTC-4, egaumer wrote: > > > > > We run inside a servlet container by implementing our own RestChannel. > > [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java) > > > > This lets us intercept every call and run custom security logic before > > > handing it off to elasticsearch and we don't have to reimplement every > > > endpoint via the Java API. > > > > > > In terms of Jetty, what I mean is that we don't produce a WAR, rather > > > we > > > embed an instance of Jetty inside the app. So we embed elasticsearch > > > inside > > > our app along side of Jetty. We debated of over using servlets but we > > > decided Spring Security was worth it. We're using Servlet 3.0 (async) > > > and > > > we're happy with the choice because it gives us a lot of capability. > > > > > > -Eric > > > > > > On Friday, April 12, 2013 9:28:46 AM UTC-4, AlexR wrote: > > > > > > > Eric, > > > > > > > > Could you elaborate a bit. You say you embed elastic rather than using > > > > plugin strategy. Do you run it within a servlet container and > > > > replicate > > > > complete API with your ACL checks before making the same elastic call? > > > > Do > > > > you call elastic via java API or pass http request on to elastic http > > > > endpoint. Also you said you use embedded jetty. I am confused a bit > > > > what's > > > > embedded in what - elastic or jetty? > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > > > > > > > > > We built an OAuth2 layer with full index level ACL support on top of > > > > > elasticsearch (opposed to using the plugin architecture). This allows > > > > > us to > > > > > control every aspect and elasticsearch embeds really well. We > > > > > restrict > > > > > access to the transport though so you have to use HTTPS (no TCP). We > > > > > support > > > > > SPDY and use an embedded instance of Jetty with async servlets (to > > > > > support > > > > > Spring Security). > > > > > > > > > > -Eric > > > > > > > > > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > > > > > > > > > Greetings, > > > > > > > > > > > > We are in the process of building out an Elasticsearch cluster, and > > > > > > we > > > > > > need security. (it's too easy to do scary things to the cluster) > > > > > > Currently we use OAuth2 for Service-to-service security in our SOA > > > > > > (although only 2-legged instead of 3). > > > > > > And we need to add this functionality for elasticsearch. > > > > > > > > > > > > We understand that we can pretty easily secure the HTTP port (9200) > > > > > > -- > > > > > > teh jetty plugin, etc. > > > > > > But we will be using the TCP port (9300), and need to secure it as > > > > > > well > > > > > > (or it defeats the purpose). > > > > > > > > > > > > First, obviously -- has anyone out there already done this?? And if > > > > > > so, > > > > > > is the code out there in the wild... > > > > > > > > > > > > Second, my goggling says that we'll probably need to build this > > > > > > ourselves. > > > > > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > > > > > > > > > Thanks, > > > > > > -- Chris > > > > -- > > You received this message because you are subscribed to the Google > > Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![mattweber](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mattweber/32/44940_2.png) [@mattweber](https://discuss.elastic.co/u/mattweber)\ **Post date:** [April 17, 2013, 11:51pm UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/9 "2013-04-17T23:51:14Z")
It is very similar to the wares transport with the exception of using spring so we can take advantage of spring security. [GitHub - elastic/elasticsearch-transport-wares: Servlet transport for Elasticsearch](https://github.com/elasticsearch/elasticsearch-transport-wares) The hard part is integrating spring security with oauth2 and using elasticsearch vs. a database for the acl information. I am sure Eric is going to do a writeup about that at some point. Thanks, Matt Weber On Wed, Apr 17, 2013 at 3:24 PM, AlexR [roytmana@gmail.com](mailto:roytmana@gmail.com) wrote: > I see Matt thanks it makes sense. > I wish I could pick your brain on RestChannel if we had to go this route > (our first phase does not require any index or document level ACL just deny > update/admin functionality to the REST client which I do with apache > mod\_proxy for now. > > It would be nice if ES had a security or at least an interceptor framework > allowing to register specialized plugins rather than doing it on transport > level like jetty plugin (or your rest channel implementation if it is much > different) > > On Wednesday, April 17, 2013 5:36:55 PM UTC-4, Matt Weber wrote: > > > Hey Alex, > > > > Any node in our cluster could be the "public" endpoint so we typically > > just have a load balancer pick one of the nodes. The transport ports > > (9300, etc) are all blocked by firewall rules (except from internal > > network) and the http server (9200) is completely disabled since we > > only allow access though our secure servlet. > > > > Thanks, > > Matt Weber > > > > On Tue, Apr 16, 2013 at 10:24 AM, AlexR [royt...@gmail.com](mailto:royt...@gmail.com) wrote: > > > > > Thanks Eric for the tip! > > > > > > It is likely we will need to go this route in the future. Do you hide > > > all > > > your cluster behind a firewall so nodes (or ingesting servers/nodes if > > > any) > > > can communicate via IP safely and only expose your protected endpoint to > > > consuming applications? If you have just one "public" endpoint what > > > happens > > > if that node fails. Or it is not an issue because this node IS your > > > application. so if it is down both the node and your app are down... > > > > > > Thanks, > > > Alex > > > > > > On Friday, April 12, 2013 9:57:42 PM UTC-4, egaumer wrote: > > > > > > > We run inside a servlet container by implementing our own RestChannel. > > > > > > > > [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java) > > > > > > > > This lets us intercept every call and run custom security logic before > > > > handing it off to elasticsearch and we don't have to reimplement every > > > > endpoint via the Java API. > > > > > > > > In terms of Jetty, what I mean is that we don't produce a WAR, rather > > > > we > > > > embed an instance of Jetty inside the app. So we embed elasticsearch > > > > inside > > > > our app along side of Jetty. We debated of over using servlets but we > > > > decided Spring Security was worth it. We're using Servlet 3.0 (async) > > > > and > > > > we're happy with the choice because it gives us a lot of capability. > > > > > > > > -Eric > > > > > > > > On Friday, April 12, 2013 9:28:46 AM UTC-4, AlexR wrote: > > > > > > > > > Eric, > > > > > > > > > > Could you elaborate a bit. You say you embed elastic rather than using > > > > > plugin strategy. Do you run it within a servlet container and > > > > > replicate > > > > > complete API with your ACL checks before making the same elastic call? > > > > > Do > > > > > you call elastic via java API or pass http request on to elastic http > > > > > endpoint. Also you said you use embedded jetty. I am confused a bit > > > > > what's > > > > > embedded in what - elastic or jetty? > > > > > > > > > > Thanks, > > > > > Alex > > > > > > > > > > On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > > > > > > > > > > > We built an OAuth2 layer with full index level ACL support on top of > > > > > > elasticsearch (opposed to using the plugin architecture). This allows > > > > > > us to > > > > > > control every aspect and elasticsearch embeds really well. We > > > > > > restrict > > > > > > access to the transport though so you have to use HTTPS (no TCP). We > > > > > > support > > > > > > SPDY and use an embedded instance of Jetty with async servlets (to > > > > > > support > > > > > > Spring Security). > > > > > > > > > > > > -Eric > > > > > > > > > > > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > > > > > > > > > > > Greetings, > > > > > > > > > > > > > > We are in the process of building out an Elasticsearch cluster, and > > > > > > > we > > > > > > > need security. (it's too easy to do scary things to the cluster) > > > > > > > Currently we use OAuth2 for Service-to-service security in our SOA > > > > > > > (although only 2-legged instead of 3). > > > > > > > And we need to add this functionality for elasticsearch. > > > > > > > > > > > > > > ## We understand that we can pretty easily secure the HTTP port (9200) > > > > > > > > > > > > > > teh jetty plugin, etc. > > > > > > > But we will be using the TCP port (9300), and need to secure it as > > > > > > > well > > > > > > > (or it defeats the purpose). > > > > > > > > > > > > > > First, obviously -- has anyone out there already done this?? And if > > > > > > > so, > > > > > > > is the code out there in the wild... > > > > > > > > > > > > > > Second, my goggling says that we'll probably need to build this > > > > > > > ourselves. > > > > > > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > > > > > > > > > > > Thanks, > > > > > > > -- Chris > > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups > > > "elasticsearch" group. > > > To unsubscribe from this group and stop receiving emails from it, send > > > an > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![Hendrik](https://avatars.discourse-cdn.com/v4/letter/h/839c29/32.png) [@Hendrik](https://discuss.elastic.co/u/Hendrik)\ **Post date:** [November 20, 2013, 9:17am UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/10 "2013-11-20T09:17:55Z")
Maybe this is interesting [https://groups.google.com/forum/?fromgroups#!topic/elasticsearch/tavroa3Nw5g](https://groups.google.com/forum/?fromgroups#!topic/elasticsearch/tavroa3Nw5g) Am Donnerstag, 18. April 2013 01:51:14 UTC+2 schrieb Matt Weber: > It is very similar to the wares transport with the exception of using > spring so we can take advantage of spring security. > > [GitHub - elastic/elasticsearch-transport-wares: Servlet transport for Elasticsearch](https://github.com/elasticsearch/elasticsearch-transport-wares) > > The hard part is integrating spring security with oauth2 and using > elasticsearch vs. a database for the acl information. I am sure Eric > is going to do a writeup about that at some point. > > Thanks, > Matt Weber > > On Wed, Apr 17, 2013 at 3:24 PM, AlexR \<[royt...@gmail.com](mailto:royt...@gmail.com) \\> > wrote: > > > I see Matt thanks it makes sense. > > I wish I could pick your brain on RestChannel if we had to go this route > > (our first phase does not require any index or document level ACL just > > deny > > update/admin functionality to the REST client which I do with apache > > mod\_proxy for now. > > > > It would be nice if ES had a security or at least an interceptor > > framework > > allowing to register specialized plugins rather than doing it on > > transport > > level like jetty plugin (or your rest channel implementation if it is > > much > > different) > > > > On Wednesday, April 17, 2013 5:36:55 PM UTC-4, Matt Weber wrote: > > > > > Hey Alex, > > > > > > Any node in our cluster could be the "public" endpoint so we typically > > > just have a load balancer pick one of the nodes. The transport ports > > > (9300, etc) are all blocked by firewall rules (except from internal > > > network) and the http server (9200) is completely disabled since we > > > only allow access though our secure servlet. > > > > > > Thanks, > > > Matt Weber > > > > > > On Tue, Apr 16, 2013 at 10:24 AM, AlexR [royt...@gmail.com](mailto:royt...@gmail.com) wrote: > > > > > > > Thanks Eric for the tip! > > > > > > > > It is likely we will need to go this route in the future. Do you hide > > > > all > > > > your cluster behind a firewall so nodes (or ingesting servers/nodes > > > > if > > > > any) > > > > can communicate via IP safely and only expose your protected endpoint > > > > to > > > > consuming applications? If you have just one "public" endpoint what > > > > happens > > > > if that node fails. Or it is not an issue because this node IS your > > > > application. so if it is down both the node and your app are down... > > > > > > > > Thanks, > > > > Alex > > > > > > > > On Friday, April 12, 2013 9:57:42 PM UTC-4, egaumer wrote: > > > > > > > > > We run inside a servlet container by implementing our own > > > > > RestChannel. > > [https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java](https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/rest/RestChannel.java) > > > > > > This lets us intercept every call and run custom security logic > > > > > before > > > > > handing it off to elasticsearch and we don't have to reimplement > > > > > every > > > > > endpoint via the Java API. > > > > > > > > > > In terms of Jetty, what I mean is that we don't produce a WAR, > > > > > rather > > > > > we > > > > > embed an instance of Jetty inside the app. So we embed elasticsearch > > > > > inside > > > > > our app along side of Jetty. We debated of over using servlets but > > > > > we > > > > > decided Spring Security was worth it. We're using Servlet 3.0 > > > > > (async) > > > > > and > > > > > we're happy with the choice because it gives us a lot of capability. > > > > > > > > > > -Eric > > > > > > > > > > On Friday, April 12, 2013 9:28:46 AM UTC-4, AlexR wrote: > > > > > > > > > > > Eric, > > > > > > > > > > > > Could you elaborate a bit. You say you embed elastic rather than > > > > > > using > > > > > > plugin strategy. Do you run it within a servlet container and > > > > > > replicate > > > > > > complete API with your ACL checks before making the same elastic > > > > > > call? > > > > > > Do > > > > > > you call elastic via java API or pass http request on to elastic > > > > > > http > > > > > > endpoint. Also you said you use embedded jetty. I am confused a bit > > > > > > what's > > > > > > embedded in what - elastic or jetty? > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > On Wednesday, April 10, 2013 6:22:30 PM UTC-4, egaumer wrote: > > > > > > > > > > > > > We built an OAuth2 layer with full index level ACL support on top > > > > > > > of > > > > > > > elasticsearch (opposed to using the plugin architecture). This > > > > > > > allows > > > > > > > us to > > > > > > > control every aspect and elasticsearch embeds really well. We > > > > > > > restrict > > > > > > > access to the transport though so you have to use HTTPS (no TCP). > > > > > > > We > > > > > > > support > > > > > > > SPDY and use an embedded instance of Jetty with async servlets (to > > > > > > > support > > > > > > > Spring Security). > > > > > > > > > > > > > > -Eric > > > > > > > > > > > > > > On Wednesday, April 10, 2013 4:30:38 PM UTC-4, Chris Berry wrote: > > > > > > > > > > > > > > > Greetings, > > > > > > > > > > > > > > > > We are in the process of building out an Elasticsearch cluster, > > > > > > > > and > > > > > > > > we > > > > > > > > need security. (it's too easy to do scary things to the cluster) > > > > > > > > Currently we use OAuth2 for Service-to-service security in our > > > > > > > > SOA > > > > > > > > (although only 2-legged instead of 3). > > > > > > > > And we need to add this functionality for elasticsearch. > > > > > > > > > > > > > > > > ## We understand that we can pretty easily secure the HTTP port (9200) > > > > > > > > > > > > > > > > teh jetty plugin, etc. > > > > > > > > But we will be using the TCP port (9300), and need to secure it > > > > > > > > as > > > > > > > > well > > > > > > > > (or it defeats the purpose). > > > > > > > > > > > > > > > > First, obviously -- has anyone out there already done this?? And > > > > > > > > if > > > > > > > > so, > > > > > > > > is the code out there in the wild... > > > > > > > > > > > > > > > > Second, my goggling says that we'll probably need to build this > > > > > > > > ourselves. > > > > > > > > Is creating/wiring in a Transport Plugin the correct approach?? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > -- Chris > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > "elasticsearch" group. > > > > To unsubscribe from this group and stop receiving emails from it, > > > > send > > > > an > > > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com). > > > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). > > > > -- > > You received this message because you are subscribed to the Google > > Groups > > "elasticsearch" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an > > email to [elasticsearc...@googlegroups.com](mailto:elasticsearc...@googlegroups.com) \. > > For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 2:06am UTC](https://discuss.elastic.co/t/creating-an-oauth2-plugin/11537/11 "2017-07-06T02:06:02Z")