SAML Issue with JwsCompactConsumer

dc...@galileo.io

unread,

Sep 27, 2018, 4:11:14 PM9/27/18

to Search Guard Community Forum

Hi,

I've enabled a Search Guard license and am seeing the following in the Elasticsearch logs.

org.apache.cxf.rs.security.jose.jws.JwsCompactConsumer <init>

WARNING: Compact JWS does not have 3 parts

What could be causing that error? I'm trying to enable SAML logins to Elasticsearch. I'm receiving an error from Google:

"400. That’s an error. Invalid Request, invalid idpId in request URL, check if SSO URL is configured properly on SP side. That’s all we know."

Is there anything that looks off to you that could potentially be a problem with my configuration?

acs returns as a 302 and yields the following data from SAMLResponse (translated from base64 encoded XML using https://www.base64decode.org/):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://kibana.galileo.io:443/searchguard/saml/acs" ID="_######" IssueInstant="2018-09-27T19:49:51.959Z" Version="2.0">

<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://accounts.google.com/o/saml2?idpid=#####</saml2:Issuer>

<saml2p:Status>

<saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>

</saml2p:Status>

<saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_#####" IssueInstant="2018-09-27T19:49:51.959Z" Version="2.0">

<saml2:Issuer>https://accounts.google.com/o/saml2?idpid=#####</saml2:Issuer>

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

<ds:Reference URI="#_#####">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue>#####</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>#####</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509SubjectName>ST=California,C=US,OU=Google For Work,CN=Google,L=Mountain View,O=Google Inc.</ds:X509SubjectName>

<ds:X509Certificate>######</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</ds:Signature>

<saml2:Subject>

<saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">####@galileo.io</saml2:NameID>

<saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

<saml2:SubjectConfirmationData NotOnOrAfter="2018-09-27T19:54:51.959Z" Recipient="https://kibana.galileo.io:443/searchguard/saml/acs"/>

</saml2:SubjectConfirmation>

</saml2:Subject>

<saml2:Conditions NotBefore="2018-09-27T19:44:51.959Z" NotOnOrAfter="2018-09-27T19:54:51.959Z">

<saml2:AudienceRestriction>

<saml2:Audience>https://kibana.galileo.io:443/searchguard/saml/acs</saml2:Audience>

</saml2:AudienceRestriction>

</saml2:Conditions>

<saml2:AttributeStatement>

<saml2:Attribute Name="role">

<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:anyType">readall</saml2:AttributeValue>

<saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:anyType">kibanauser</saml2:AttributeValue>

</saml2:Attribute>

</saml2:AttributeStatement>

<saml2:AuthnStatement AuthnInstant="2018-09-27T19:11:25.000Z" SessionIndex="_#####">

<saml2:AuthnContext>

<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml2:AuthnContextClassRef>

</saml2:AuthnContext>

</saml2:AuthnStatement>

</saml2:Assertion>

</saml2p:Response>

Thanks,

Dan

When asking questions, please provide the following information:

* Search Guard and Elasticsearch version: 6.4.1

[2018-09-27T18:57:11,174][INFO ][c.f.s.c.IndexBaseConfigurationRepository] Search Guard License Type: FULL, valid

* Installed and used enterprise modules, if any:

[2018-09-27T18:57:00,041][INFO ][c.f.s.SearchGuardPlugin ] 4 Search Guard modules loaded so far: [Module [type=REST_MANAGEMENT_API, implementing class=com.floragunn.searchguard.dlic.rest.api.SearchGuardRestApiActions], Module [type=AUDITLOG, implementing class=com.floragunn.searchguard.auditlog.impl.AuditLogImpl], Module [type=MULTITENANCY, implementing class=com.floragunn.searchguard.configuration.PrivilegesInterceptorImpl], Module [type=DLSFLS, implementing class=com.floragunn.searchguard.configuration.SearchGuardFlsDlsIndexSearcherWrapper]]

* JVM version and operating system version

$ java -version

openjdk version "1.8.0_181"

OpenJDK Runtime Environment (build 1.8.0_181-b13)

OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)

$ cat /etc/*elease

CentOS Linux release 7.5.1804 (Core)

NAME="CentOS Linux"

VERSION="7 (Core)"

ID="centos"

ID_LIKE="rhel fedora"

VERSION_ID="7"

PRETTY_NAME="CentOS Linux 7 (Core)"

ANSI_COLOR="0;31"

CPE_NAME="cpe:/o:centos:centos:7"

HOME_URL="https://www.centos.org/"

BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"

CENTOS_MANTISBT_PROJECT_VERSION="7"

REDHAT_SUPPORT_PRODUCT="centos"

REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.5.1804 (Core)

* Search Guard configuration files

elasticsearch.yml

searchguard.enterprise_modules_enabled: true

searchguard.compliance.history.internal_config_enabled: true

searchguard.compliance.history.external_config_enabled: true

searchguard.compliance.history.read.metadata_only: true

sg_config.yml

authc:

basic_internal_auth_domain:

enabled: true

order: 0

http_authenticator:

type: basic

challenge: false

authentication_backend:

type: intern

saml_auth_domain_google:

http_enabled: true

transport_enabled: true

order: 1

http_authenticator:

type: 'saml'

challenge: true

config:

idp:

metadata_file: GoogleIDPMetadata-galileo.io.xml

entity_id: https://accounts.google.com/o/saml2?idpid=###########

sp:

entity_id: __SP_ENTITY_ID__

kibana_url: __KIBANA_URL__

roles_key: role

exchange_key: '__SAML_EXCHANGE_KEY__'

authentication_backend:

type: noop

* Elasticsearch log messages on debug level

* Other installed Elasticsearch or Kibana plugins, if any

dc...@galileo.io

unread,

Sep 27, 2018, 4:39:44 PM9/27/18

to Search Guard Community Forum

To add some additional context:

When visiting kibana.galileo.io, I am redirected to https://accounts.google.com/o/saml2/idp?idpid=#####?SAMLRequest=nZJNbxoxEIb%2Fysr3%2FYKFTS...

There are two question marks in that URL, and replacing the second question mark with an ampersand yields

https://accounts.google.com/o/saml2/idp?idpid=#####&SAMLRequest=nZJNbxoxEIb%2Fysr3%2FYKFTS...

The first URL with two question marks creates a 400. The second URL with a question mark followed by an ampersand yields a correct logout.

Do you have any more information on if this could be fixed from the Search Guard side?

I noticed a similar post in Artifactory about SAML SSO with Google.

https://www.jfrog.com/jira/si/jira.issueviews:issue-html/RTFACT-10242/RTFACT-10242.html

Thanks,

Dan

dc...@galileo.io

unread,

Sep 27, 2018, 5:27:55 PM9/27/18

to Search Guard Community Forum

I'm also noticing in the headers for a response to Elasticsearch.

I'm receiving a 401 response, even while passing basic auth credentials.

Is this related to my error with Google IdP?

curl --user admin:password "https://elasticsearch.galileo.io:443" -v

* Rebuilt URL to: https://elasticsearch.galileo.io:443/

* Trying 123.456.789.0...

* TCP_NODELAY set

* Connected to elasticsearch.galileo.io (123.456.789.0) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

* CAfile: /etc/ssl/cert.pem

CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Client hello (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256

* ALPN, server accepted to use h2

* Server certificate:

* subject: CN=*.galileo.io

* start date: Mar 7 00:00:00 2018 GMT

* expire date: Apr 7 12:00:00 2019 GMT

* subjectAltName: host "elasticsearch.galileo.io" matched cert's "*.galileo.io"

* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon

* SSL certificate verify ok.

* Using HTTP2, server supports multi-use

* Connection state changed (HTTP/2 confirmed)

* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0

* Server auth using Basic with user 'admin'

* Using Stream ID: 1 (easy handle 0x7fda03000800)

> GET / HTTP/2

> Host: elasticsearch.galileo.io

> Authorization: Basic #####=

> User-Agent: curl/7.54.0

> Accept: */*

>

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!

< HTTP/2 401

< date: Thu, 27 Sep 2018 21:26:17 GMT

< content-type: text/plain; charset=UTF-8

< content-length: 0

< www-authenticate: X-SG-IdP realm="Search Guard" location="https://accounts.google.com/o/saml2/idp?idpid=#####?SAMLRequest=nZJLb%2BMgFIX%2FisXezzp...." requestId="ONELOGIN_######-####-####-####-######"

<

* Connection #0 to host elasticsearch.galileo.io left intact

Thanks,

Dan

Jochen Kressin

unread,

Sep 28, 2018, 5:31:10 AM9/28/18

to Search Guard Community Forum

We investigated this and it could be a bug in the SAML module in case the IdP URL contains a query string. Could you please open a bug on GitHub?

https://github.com/floragunncom/search-guard/issues

Thanks!

dc...@galileo.io

unread,

Sep 28, 2018, 10:33:39 AM9/28/18

to Search Guard Community Forum

Opened a GitHub Issue here: https://github.com/floragunncom/search-guard/issues/560

Has this issue shown up before, in different ways, perhaps? Hopeful that there is a way to deal with the IdP URL additional query string.

Jochen Kressin

unread,

Oct 1, 2018, 10:19:34 AM10/1/18

to Search Guard Community Forum

No, not yet, but it is indeed a bug. We have found and fixed it so it will be included in the next SG release.

Reply all

Reply to author

Forward