SAML and OpenID officially released with Search Guard v23

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team

···

Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

HI Jochen

I’m trying to set up SAML authentication for Searchguard using Microsoft ADFS 3 as my IdP. I’ve got it to the stage where I get redirected to ADFS to authenticate, but when my browser is redirected to the Assertion Consumer URL (/searchguard/saml/acs) I get a 404 error on screen and in the Kibana log. Any ideas what I should be looking at?

Thanks

Max

  • Search Guard and Elasticsearch version: ES 6.2.4, SG 6.2.4-23.0, Kibana/SG 6.2.4-14beta1

  • Installed and used enterprise modules, if any: SAML

  • JVM version and operating system version: Oracle Java 8u171-1, Debian 9.4

  • Search Guard configuration files: attached

  • Elasticsearch log messages on debug level: don’t currently have these available

  • Other installed Elasticsearch or Kibana plugins, if any: none

sgconf.tar.gz (6.55 KB)

···

On Thu, 16 Aug 2018 at 14:16, Jochen Kressin jkressin@floragunn.com wrote:

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team


Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/88467f73-1748-419b-9b11-aa331dd88593%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Did you add the ACS enndpoint to the xsrf wihitelist?

server.xsrf.whitelist: [“/searchguard/saml/acs”, “/searchguard/saml/logout”]

``

https://docs.search-guard.com/latest/kibana-authentication-saml

We have customers using SAML with ADFS, so it is known to work.

···

On Tuesday, August 28, 2018 at 12:25:37 PM UTC-4, Max Caines wrote:

HI Jochen

I’m trying to set up SAML authentication for Searchguard using Microsoft ADFS 3 as my IdP. I’ve got it to the stage where I get redirected to ADFS to authenticate, but when my browser is redirected to the Assertion Consumer URL (/searchguard/saml/acs) I get a 404 error on screen and in the Kibana log. Any ideas what I should be looking at?

Thanks

Max

  • Search Guard and Elasticsearch version: ES 6.2.4, SG 6.2.4-23.0, Kibana/SG 6.2.4-14beta1
  • Installed and used enterprise modules, if any: SAML
  • JVM version and operating system version: Oracle Java 8u171-1, Debian 9.4
  • Search Guard configuration files: attached
  • Elasticsearch log messages on debug level: don’t currently have these available
  • Other installed Elasticsearch or Kibana plugins, if any: none

On Thu, 16 Aug 2018 at 14:16, Jochen Kressin jkressin@floragunn.com wrote:

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team


Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/88467f73-1748-419b-9b11-aa331dd88593%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi Jochen

Yes, I did. I’m assuming that goes in kibana.yml. I guess I should check for typos. Good to hear that I’m not the first using ADFS

Thanks

Max

···

On Tue, 28 Aug 2018 at 19:36, Jochen Kressin jkressin@floragunn.com wrote:

Did you add the ACS enndpoint to the xsfrf wihitelist?

server.xsrf.whitelist: [“/searchguard/saml/acs”, “/searchguard/saml/logout”]

``

https://docs.search-guard.com/latest/kibana-authentication-saml

We have customers using SAML with ADFS, so it is known to work.

On Tuesday, August 28, 2018 at 12:25:37 PM UTC-4, Max Caines wrote:

HI Jochen

I’m trying to set up SAML authentication for Searchguard using Microsoft ADFS 3 as my IdP. I’ve got it to the stage where I get redirected to ADFS to authenticate, but when my browser is redirected to the Assertion Consumer URL (/searchguard/saml/acs) I get a 404 error on screen and in the Kibana log. Any ideas what I should be looking at?

Thanks

Max

  • Search Guard and Elasticsearch version: ES 6.2.4, SG 6.2.4-23.0, Kibana/SG 6.2.4-14beta1
  • Installed and used enterprise modules, if any: SAML
  • JVM version and operating system version: Oracle Java 8u171-1, Debian 9.4
  • Search Guard configuration files: attached
  • Elasticsearch log messages on debug level: don’t currently have these available
  • Other installed Elasticsearch or Kibana plugins, if any: none

On Thu, 16 Aug 2018 at 14:16, Jochen Kressin jkressin@floragunn.com wrote:

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team


Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/88467f73-1748-419b-9b11-aa331dd88593%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f4fa2a03-c297-4da2-8e67-2c8f98887790%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi Jochen

I’ve got a lot further (replaced the beta of the Kibana plugin with the release version), but I’m now baffled. Elasticsearch is getting, and accepting, a SAML response from ADFS containing a user name and role. It creates a JWT token, but then says:

[2018-08-29T11:14:39,103][DEBUG][c.o.s.a.SamlResponse ] SAMLResponse has NameID → in1012

[2018-08-29T11:14:39,146][DEBUG][c.o.s.a.SamlResponse ] SAMLResponse has attributes: {http://schemas.microsoft.com/ws/2008/06/identity/claims/role=[staff]}

[2018-08-29T11:14:39,163][DEBUG][c.f.d.a.h.s.Token ] Created JWT: eyJhbGciOiJIUzUxMiJ9.eyJuYmYiOjE1MzU1Mzc2NzksImV4cCI6MTUzNTU0MTI3OSwic3ViIjoiaW4xMDEyIiwic2FtbF9zaSI6Il8wZTlhODEwOC03NWY4LTQ5OTktYjdjNi03MGVhMThmNDljODEiLCJyb2xlcyI6WyJzdGFmZiJdfQ.WqYTtYZaYaAeynycfr_jSQPrp0-no6PIA26CrXR9qRVCtDUt6JYH-8f2tZp0_d5kPtgdFOuaSLJK1dELhMl1iQ

{“alg”:“HS512”}

{“nbf”:1535537679,“exp”:1535541279,“sub”:“in1012”,“saml_si”:“_0e9a8108-75f8-4999-b7c6-70ea18f49c81”,“roles”:[“staff”]}

[2018-08-29T11:14:39,240][WARN ][c.f.s.h.HTTPBasicAuthenticator] No ‘Basic Authorization’ header, send 401 and ‘WWW-Authenticate Basic’

[2018-08-29T11:14:39,258][DEBUG][c.f.s.a.BackendRegistry ] in1012 not cached, return from internal backend directly

[2018-08-29T11:14:39,259][DEBUG][c.f.s.a.BackendRegistry ] Can not authenticate in1012 due to com.google.common.util.concurrent.UncheckedExecutionException: ElasticsearchSecurityException[in1012 not found]

com.google.common.util.concurrent.UncheckedExecutionException: ElasticsearchSecurityException[in1012 not found]

I don’t understand what it’s up to. The Kibana log, even set to “debug”, has little around this time - just the redirect from ADFS, and then the SAML error that appears onscreen:

{“type”:“response”,“@timestamp”:“2018-08-29T10:14:38Z”,“tags”:,“pid”:9060,“method”:“post”,“statusCode”:302,“req”:{“url”:“/searchguard/saml/acs”,“method”:“post”,“headers”:{“host”:“jruby.wlv.ac.uk”,“connection”:“keep-alive”,“content-length”:“5205”,“cache-control”:“max-age=0”,“origin”:“https://sso.wlv.ac.uk”,“upgrade-insecure-requests”:“1”,“content-type”:“application/x-www-form-urlencoded”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”,“accept-encoding”:“gzip, deflate, br”,“accept-language”:“en-US,en;q=0.9,en-GB;q=0.8”},“remoteAddress”:“134.220.193.4”,“userAgent”:“134.220.193.4”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”},“res”:{“statusCode”:302,“responseTime”:1064,“contentLength”:9},“message”:“POST /searchguard/saml/acs 302 1064ms - 9.0B”}

{“type”:“ops”,“@timestamp”:“2018-08-29T10:14:39Z”,“tags”:,“pid”:9060,“os”:{“load”:[0.517578125,0.1748046875,0.17333984375],“mem”:{“total”:8376090624,“free”:1717936128},“uptime”:6134972},“proc”:{“uptime”:53.008,“mem”:{“rss”:168538112,“heapTotal”:137834496,“heapUsed”:125732328,“external”:689483},“delay”:1.7034826278686523},“load”:{“requests”:{“443”:{“total”:2,“disconnects”:0,“statusCodes”:{“302”:1}}},“concurrents”:{“443”:5},“responseTimes”:{“443”:{“avg”:1064,“max”:1064}},“sockets”:{“http”:{“total”:0},“https”:{“total”:0}}},“message”:“memory: 119.9MB uptime: 0:00:53 load: [0.52 0.17 0.17] delay: 1.703”}

{“type”:“response”,“@timestamp”:“2018-08-29T10:14:39Z”,“tags”:,“pid”:9060,“method”:“get”,“statusCode”:200,“req”:{“url”:“/customerror?type=samlAuthError”,“method”:“get”,“headers”:{“host”:“jruby.wlv.ac.uk”,“connection”:“keep-alive”,“cache-control”:“max-age=0”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”,“accept-encoding”:“gzip, deflate, br”,“accept-language”:“en-US,en;q=0.9,en-GB;q=0.8”},“remoteAddress”:“134.220.193.4”,“userAgent”:“134.220.193.4”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”},“res”:{“statusCode”:200,“responseTime”:354,“contentLength”:9},“message”:“GET /customerror?type=samlAuthError 200 354ms - 9.0B”}

It seems like the authentication is succeeding, but Kibana is not happy in some way, since it’s not sending Authorization headers to Elasticsearch. I’m baffled by this. Any ideas? I’ve attached the current config fies, and I can supply full logs for ES and Kibana, but the are big (~25M)

Thanks

Max

sgconfig.tar.gz (6.66 KB)

conf.tar.gz (3.49 KB)

···

On Tue, 28 Aug 2018 at 20:25, Max Caines maxcaines0@gmail.com wrote:

Hi Jochen

Yes, I did. I’m assuming that goes in kibana.yml. I guess I should check for typos. Good to hear that I’m not the first using ADFS

Thanks

Max

On Tue, 28 Aug 2018 at 19:36, Jochen Kressin jkressin@floragunn.com wrote:

Did you add the ACS enndpoint to the xsfrf wihitelist?

server.xsrf.whitelist: [“/searchguard/saml/acs”, “/searchguard/saml/logout”]

``

https://docs.search-guard.com/latest/kibana-authentication-saml

We have customers using SAML with ADFS, so it is known to work.

On Tuesday, August 28, 2018 at 12:25:37 PM UTC-4, Max Caines wrote:

HI Jochen

I’m trying to set up SAML authentication for Searchguard using Microsoft ADFS 3 as my IdP. I’ve got it to the stage where I get redirected to ADFS to authenticate, but when my browser is redirected to the Assertion Consumer URL (/searchguard/saml/acs) I get a 404 error on screen and in the Kibana log. Any ideas what I should be looking at?

Thanks

Max

  • Search Guard and Elasticsearch version: ES 6.2.4, SG 6.2.4-23.0, Kibana/SG 6.2.4-14beta1
  • Installed and used enterprise modules, if any: SAML
  • JVM version and operating system version: Oracle Java 8u171-1, Debian 9.4
  • Search Guard configuration files: attached
  • Elasticsearch log messages on debug level: don’t currently have these available
  • Other installed Elasticsearch or Kibana plugins, if any: none

On Thu, 16 Aug 2018 at 14:16, Jochen Kressin jkressin@floragunn.com wrote:

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team


Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/88467f73-1748-419b-9b11-aa331dd88593%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f4fa2a03-c297-4da2-8e67-2c8f98887790%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi Jochen

OK, sorted. The problem was that I had too much indentation on the “authentication_backend” line in the “saml” section of “sg_config.yml”. As a result the authentication backend was defaulting to “internal”, and my account is not listed in that backend. The use of indentation to structure YML files makes them easy to write, but also easy to screw up!

Thanks

Max

···

On Wed, 29 Aug 2018 at 11:33, Max Caines maxcaines0@gmail.com wrote:

Hi Jochen

I’ve got a lot further (replaced the beta of the Kibana plugin with the release version), but I’m now baffled. Elasticsearch is getting, and accepting, a SAML response from ADFS containing a user name and role. It creates a JWT token, but then says:

[2018-08-29T11:14:39,103][DEBUG][c.o.s.a.SamlResponse ] SAMLResponse has NameID → in1012

[2018-08-29T11:14:39,146][DEBUG][c.o.s.a.SamlResponse ] SAMLResponse has attributes: {http://schemas.microsoft.com/ws/2008/06/identity/claims/role=[staff]}

[2018-08-29T11:14:39,163][DEBUG][c.f.d.a.h.s.Token ] Created JWT: eyJhbGciOiJIUzUxMiJ9.eyJuYmYiOjE1MzU1Mzc2NzksImV4cCI6MTUzNTU0MTI3OSwic3ViIjoiaW4xMDEyIiwic2FtbF9zaSI6Il8wZTlhODEwOC03NWY4LTQ5OTktYjdjNi03MGVhMThmNDljODEiLCJyb2xlcyI6WyJzdGFmZiJdfQ.WqYTtYZaYaAeynycfr_jSQPrp0-no6PIA26CrXR9qRVCtDUt6JYH-8f2tZp0_d5kPtgdFOuaSLJK1dELhMl1iQ

{“alg”:“HS512”}

{“nbf”:1535537679,“exp”:1535541279,“sub”:“in1012”,“saml_si”:“_0e9a8108-75f8-4999-b7c6-70ea18f49c81”,“roles”:[“staff”]}

[2018-08-29T11:14:39,240][WARN ][c.f.s.h.HTTPBasicAuthenticator] No ‘Basic Authorization’ header, send 401 and ‘WWW-Authenticate Basic’

[2018-08-29T11:14:39,258][DEBUG][c.f.s.a.BackendRegistry ] in1012 not cached, return from internal backend directly

[2018-08-29T11:14:39,259][DEBUG][c.f.s.a.BackendRegistry ] Can not authenticate in1012 due to com.google.common.util.concurrent.UncheckedExecutionException: ElasticsearchSecurityException[in1012 not found]

com.google.common.util.concurrent.UncheckedExecutionException: ElasticsearchSecurityException[in1012 not found]

I don’t understand what it’s up to. The Kibana log, even set to “debug”, has little around this time - just the redirect from ADFS, and then the SAML error that appears onscreen:

{“type”:“response”,“@timestamp”:“2018-08-29T10:14:38Z”,“tags”:,“pid”:9060,“method”:“post”,“statusCode”:302,“req”:{“url”:“/searchguard/saml/acs”,“method”:“post”,“headers”:{“host”:“jruby.wlv.ac.uk”,“connection”:“keep-alive”,“content-length”:“5205”,“cache-control”:“max-age=0”,“origin”:“https://sso.wlv.ac.uk”,“upgrade-insecure-requests”:“1”,“content-type”:“application/x-www-form-urlencoded”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”,“accept-encoding”:“gzip, deflate, br”,“accept-language”:“en-US,en;q=0.9,en-GB;q=0.8”},“remoteAddress”:“134.220.193.4”,“userAgent”:“134.220.193.4”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”},“res”:{“statusCode”:302,“responseTime”:1064,“contentLength”:9},“message”:“POST /searchguard/saml/acs 302 1064ms - 9.0B”}

{“type”:“ops”,“@timestamp”:“2018-08-29T10:14:39Z”,“tags”:,“pid”:9060,“os”:{“load”:[0.517578125,0.1748046875,0.17333984375],“mem”:{“total”:8376090624,“free”:1717936128},“uptime”:6134972},“proc”:{“uptime”:53.008,“mem”:{“rss”:168538112,“heapTotal”:137834496,“heapUsed”:125732328,“external”:689483},“delay”:1.7034826278686523},“load”:{“requests”:{“443”:{“total”:2,“disconnects”:0,“statusCodes”:{“302”:1}}},“concurrents”:{“443”:5},“responseTimes”:{“443”:{“avg”:1064,“max”:1064}},“sockets”:{“http”:{“total”:0},“https”:{“total”:0}}},“message”:“memory: 119.9MB uptime: 0:00:53 load: [0.52 0.17 0.17] delay: 1.703”}

{“type”:“response”,“@timestamp”:“2018-08-29T10:14:39Z”,“tags”:,“pid”:9060,“method”:“get”,“statusCode”:200,“req”:{“url”:“/customerror?type=samlAuthError”,“method”:“get”,“headers”:{“host”:“jruby.wlv.ac.uk”,“connection”:“keep-alive”,“cache-control”:“max-age=0”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”,“accept-encoding”:“gzip, deflate, br”,“accept-language”:“en-US,en;q=0.9,en-GB;q=0.8”},“remoteAddress”:“134.220.193.4”,“userAgent”:“134.220.193.4”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”},“res”:{“statusCode”:200,“responseTime”:354,“contentLength”:9},“message”:“GET /customerror?type=samlAuthError 200 354ms - 9.0B”}

It seems like the authentication is succeeding, but Kibana is not happy in some way, since it’s not sending Authorization headers to Elasticsearch. I’m baffled by this. Any ideas? I’ve attached the current config fies, and I can supply full logs for ES and Kibana, but the are big (~25M)

Thanks

Max

On Tue, 28 Aug 2018 at 20:25, Max Caines maxcaines0@gmail.com wrote:

Hi Jochen

Yes, I did. I’m assuming that goes in kibana.yml. I guess I should check for typos. Good to hear that I’m not the first using ADFS

Thanks

Max

On Tue, 28 Aug 2018 at 19:36, Jochen Kressin jkressin@floragunn.com wrote:

Did you add the ACS enndpoint to the xsfrf wihitelist?

server.xsrf.whitelist: [“/searchguard/saml/acs”, “/searchguard/saml/logout”]

``

https://docs.search-guard.com/latest/kibana-authentication-saml

We have customers using SAML with ADFS, so it is known to work.

On Tuesday, August 28, 2018 at 12:25:37 PM UTC-4, Max Caines wrote:

HI Jochen

I’m trying to set up SAML authentication for Searchguard using Microsoft ADFS 3 as my IdP. I’ve got it to the stage where I get redirected to ADFS to authenticate, but when my browser is redirected to the Assertion Consumer URL (/searchguard/saml/acs) I get a 404 error on screen and in the Kibana log. Any ideas what I should be looking at?

Thanks

Max

  • Search Guard and Elasticsearch version: ES 6.2.4, SG 6.2.4-23.0, Kibana/SG 6.2.4-14beta1
  • Installed and used enterprise modules, if any: SAML
  • JVM version and operating system version: Oracle Java 8u171-1, Debian 9.4
  • Search Guard configuration files: attached
  • Elasticsearch log messages on debug level: don’t currently have these available
  • Other installed Elasticsearch or Kibana plugins, if any: none

On Thu, 16 Aug 2018 at 14:16, Jochen Kressin jkressin@floragunn.com wrote:

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team


Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/88467f73-1748-419b-9b11-aa331dd88593%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f4fa2a03-c297-4da2-8e67-2c8f98887790%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Hi Max, glad you sorted it out. I think we will need to provide some tools to check the configs in future, it’s too easy to make mistakes in yaml :wink:

···

On Wednesday, August 29, 2018 at 7:39:35 AM UTC-4, Max Caines wrote:

Hi Jochen

OK, sorted. The problem was that I had too much indentation on the “authentication_backend” line in the “saml” section of “sg_config.yml”. As a result the authentication backend was defaulting to “internal”, and my account is not listed in that backend. The use of indentation to structure YML files makes them easy to write, but also easy to screw up!

Thanks

Max

On Wed, 29 Aug 2018 at 11:33, Max Caines maxcaines0@gmail.com wrote:

Hi Jochen

I’ve got a lot further (replaced the beta of the Kibana plugin with the release version), but I’m now baffled. Elasticsearch is getting, and accepting, a SAML response from ADFS containing a user name and role. It creates a JWT token, but then says:

[2018-08-29T11:14:39,103][DEBUG][c.o.s.a.SamlResponse ] SAMLResponse has NameID → in1012

[2018-08-29T11:14:39,146][DEBUG][c.o.s.a.SamlResponse ] SAMLResponse has attributes: {http://schemas.microsoft.com/ws/2008/06/identity/claims/role=[staff]}

[2018-08-29T11:14:39,163][DEBUG][c.f.d.a.h.s.Token ] Created JWT: eyJhbGciOiJIUzUxMiJ9.eyJuYmYiOjE1MzU1Mzc2NzksImV4cCI6MTUzNTU0MTI3OSwic3ViIjoiaW4xMDEyIiwic2FtbF9zaSI6Il8wZTlhODEwOC03NWY4LTQ5OTktYjdjNi03MGVhMThmNDljODEiLCJyb2xlcyI6WyJzdGFmZiJdfQ.WqYTtYZaYaAeynycfr_jSQPrp0-no6PIA26CrXR9qRVCtDUt6JYH-8f2tZp0_d5kPtgdFOuaSLJK1dELhMl1iQ

{“alg”:“HS512”}

{“nbf”:1535537679,“exp”:1535541279,“sub”:“in1012”,“saml_si”:“_0e9a8108-75f8-4999-b7c6-70ea18f49c81”,“roles”:[“staff”]}

[2018-08-29T11:14:39,240][WARN ][c.f.s.h.HTTPBasicAuthenticator] No ‘Basic Authorization’ header, send 401 and ‘WWW-Authenticate Basic’

[2018-08-29T11:14:39,258][DEBUG][c.f.s.a.BackendRegistry ] in1012 not cached, return from internal backend directly

[2018-08-29T11:14:39,259][DEBUG][c.f.s.a.BackendRegistry ] Can not authenticate in1012 due to com.google.common.util.concurrent.UncheckedExecutionException: ElasticsearchSecurityException[in1012 not found]

com.google.common.util.concurrent.UncheckedExecutionException: ElasticsearchSecurityException[in1012 not found]

I don’t understand what it’s up to. The Kibana log, even set to “debug”, has little around this time - just the redirect from ADFS, and then the SAML error that appears onscreen:

{“type”:“response”,“@timestamp”:“2018-08-29T10:14:38Z”,“tags”:,“pid”:9060,“method”:“post”,“statusCode”:302,“req”:{“url”:“/searchguard/saml/acs”,“method”:“post”,“headers”:{“host”:“jruby.wlv.ac.uk”,“connection”:“keep-alive”,“content-length”:“5205”,“cache-control”:“max-age=0”,“origin”:“https://sso.wlv.ac.uk”,“upgrade-insecure-requests”:“1”,“content-type”:“application/x-www-form-urlencoded”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”,“accept-encoding”:“gzip, deflate, br”,“accept-language”:“en-US,en;q=0.9,en-GB;q=0.8”},“remoteAddress”:“134.220.193.4”,“userAgent”:“134.220.193.4”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”},“res”:{“statusCode”:302,“responseTime”:1064,“contentLength”:9},“message”:“POST /searchguard/saml/acs 302 1064ms - 9.0B”}

{“type”:“ops”,“@timestamp”:“2018-08-29T10:14:39Z”,“tags”:,“pid”:9060,“os”:{“load”:[0.517578125,0.1748046875,0.17333984375],“mem”:{“total”:8376090624,“free”:1717936128},“uptime”:6134972},“proc”:{“uptime”:53.008,“mem”:{“rss”:168538112,“heapTotal”:137834496,“heapUsed”:125732328,“external”:689483},“delay”:1.7034826278686523},“load”:{“requests”:{“443”:{“total”:2,“disconnects”:0,“statusCodes”:{“302”:1}}},“concurrents”:{“443”:5},“responseTimes”:{“443”:{“avg”:1064,“max”:1064}},“sockets”:{“http”:{“total”:0},“https”:{“total”:0}}},“message”:“memory: 119.9MB uptime: 0:00:53 load: [0.52 0.17 0.17] delay: 1.703”}

{“type”:“response”,“@timestamp”:“2018-08-29T10:14:39Z”,“tags”:,“pid”:9060,“method”:“get”,“statusCode”:200,“req”:{“url”:“/customerror?type=samlAuthError”,“method”:“get”,“headers”:{“host”:“jruby.wlv.ac.uk”,“connection”:“keep-alive”,“cache-control”:“max-age=0”,“upgrade-insecure-requests”:“1”,“user-agent”:“Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36”,“accept”:“text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”,“accept-encoding”:“gzip, deflate, br”,“accept-language”:“en-US,en;q=0.9,en-GB;q=0.8”},“remoteAddress”:“134.220.193.4”,“userAgent”:“134.220.193.4”,“referer”:“https://sso.wlv.ac.uk/adfs/ls/?SAMLRequest=fZJPU8IwEMW%2FSif3NC0tihlgBsE%2FzCAwgh68OEu7QKRNMJuAfHtL0REPesu83bdvf0naBGWxlT3v1voR3z2SCz7KQpOsCx3mrZYGSJHUUCJJl8lZ72EkG2Ekt9Y4k5mCnVn%2BdwARWqeMZsFw0GGT8c1ocjccv6ZJAohpwlvLPOdpCyIOzTjhUXNxUSkX2IQGC57RUuXtsGpUNYDI41CTA%2B0qKYpbPGrxxtU8jmScyvjyhQWDikdpcLVr7dyWpBBEJtwXuxCy0G8E5EsSBQkWTL9wrpXOlV79T7I4NZG8n8%2BnfDqZzVnQ%2B6brG02%2BRDtDu1MZPj2OftLfrF8cfvJlmiaCEGy2XnmwuTheooCMWLd9PMoa03Y3agEa%2BFFqi%2FNC%2B%2FSC42rD4WBqCpUdgltjS3B%2FA8RhXCsq58u6VXpNW8zUUmFecRSF2fctgsMOc9YjC0T3lPr7q3Q%2FAQ%3D%3D&client-request-id=1a1a8c26-bc26-4ba0-f805-008001000085”},“res”:{“statusCode”:200,“responseTime”:354,“contentLength”:9},“message”:“GET /customerror?type=samlAuthError 200 354ms - 9.0B”}

It seems like the authentication is succeeding, but Kibana is not happy in some way, since it’s not sending Authorization headers to Elasticsearch. I’m baffled by this. Any ideas? I’ve attached the current config fies, and I can supply full logs for ES and Kibana, but the are big (~25M)

Thanks

Max

On Tue, 28 Aug 2018 at 20:25, Max Caines maxcaines0@gmail.com wrote:

Hi Jochen

Yes, I did. I’m assuming that goes in kibana.yml. I guess I should check for typos. Good to hear that I’m not the first using ADFS

Thanks

Max

On Tue, 28 Aug 2018 at 19:36, Jochen Kressin jkressin@floragunn.com wrote:

Did you add the ACS enndpoint to the xsfrf wihitelist?

server.xsrf.whitelist: [“/searchguard/saml/acs”, “/searchguard/saml/logout”]

``

https://docs.search-guard.com/latest/kibana-authentication-saml

We have customers using SAML with ADFS, so it is known to work.

On Tuesday, August 28, 2018 at 12:25:37 PM UTC-4, Max Caines wrote:

HI Jochen

I’m trying to set up SAML authentication for Searchguard using Microsoft ADFS 3 as my IdP. I’ve got it to the stage where I get redirected to ADFS to authenticate, but when my browser is redirected to the Assertion Consumer URL (/searchguard/saml/acs) I get a 404 error on screen and in the Kibana log. Any ideas what I should be looking at?

Thanks

Max

  • Search Guard and Elasticsearch version: ES 6.2.4, SG 6.2.4-23.0, Kibana/SG 6.2.4-14beta1
  • Installed and used enterprise modules, if any: SAML
  • JVM version and operating system version: Oracle Java 8u171-1, Debian 9.4
  • Search Guard configuration files: attached
  • Elasticsearch log messages on debug level: don’t currently have these available
  • Other installed Elasticsearch or Kibana plugins, if any: none

On Thu, 16 Aug 2018 at 14:16, Jochen Kressin jkressin@floragunn.com wrote:

Hi all,

we have released Search Guard v23 and Kibana Plugin v14 which add SAML and OpenID support. Choose your favorite identity provider like Keycloak, Okta, Auth0 or OneLogin and enjoy painless and easy Kibana Single Sign-On!

Search Guard 23.0 Release Notes

Besides OpenID and SAML, the new Kibana plugin version comes with numerous fixes and improvements:

Kibana Plugin 14 Release Notes

If your keen on trying out SAML or OpenID, make sure to check our blog posts and the official documentation:

Search Guard Versions

We have merged the Search Guard Enterprise and Compliance Edition into one codebase. That means that you get all features of Search Guard in a single download. The availability of the features is merely controlled by the license. This means you can switch between Community, Enterprise and Compliance on a running system. No need for installing another plugin version or restarting your cluster.

We hope you enjoy the new features as much as we do! If you have any questions or feature requests please let us know!

Jochen and the Search Guard team


Search Guard (®) is an Elasticsearch plugin that offers encryption, authentication, and authorization.

Coded with love in Berlin, Denmark, Sweden and the US.

Search Guard is a trademark of floragunn GmbH, registered in the U.S. and in other countries.

Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/88467f73-1748-419b-9b11-aa331dd88593%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “Search Guard Community Forum” group.

To unsubscribe from this group and stop receiving emails from it, send an email to search-guard+unsubscribe@googlegroups.com.

To post to this group, send email to search-guard@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/search-guard/f4fa2a03-c297-4da2-8e67-2c8f98887790%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.