Unable to configure SAML with Jumpcloud and Opendistro

Hi team,

I have been working for couple of days on trying to setup SAML integration with Jumpcloud.
The both sides Jumpcloud and ELK has been configured, however I have been constantly redirected onto this URL: /customerror?type=samlAuthError#?_g=()

Here is part of my configuration, I will just replace sensitive data with <>:

config.yml

authc:
      basic_internal_auth_domain:
        description: "Authenticate via HTTP Basic against internal users database"
        http_enabled: true
        transport_enabled: true
        order: 0
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: internal
      saml_auth_domain:
        http_enabled: true
        transport_enabled: false
        order: 1
        http_authenticator:
          type: saml
          challenge: true
          config:
            idp:
              # metadata_file: /etc/elasticsearch/elastic-metadata-jumpcloud.xml
              metadata_file: elastic-metadata-jumpcloud.xml
              entity_id: https://<KIBANA IP>
            sp:
              entity_id: kibana-saml
            kibana_url: https://<KIBANA IP>:5601/
            subject_key: username
            roles_key: roles
            exchange_key: '<32 character long string>'
        authentication_backend:
          type: noop

kibana.yml

opendistro_security.auth.type: "saml"
server.xsrf.whitelist: ["/_opendistro/_security/saml/acs/idpinitiated", "/_opendistro/_security/saml/acs", "/_opendistro/_security/saml/logout"]

elasticsearch.ssl.verificationMode: full
server.ssl.enabled: true
server.ssl.key: /etc/kibana/kibana-key.pem
server.ssl.certificate: /etc/kibana/kibana.pem
elasticsearch.ssl.certificateAuthorities: ["/etc/kibana/root-ca.pem"]

After comiting changes security script is performed, and on relative path ‘metadata_file’ is .xml file with metadata extracted from Jumpcloud.
On Jumpcloud side we are using SAML1.0 (tried with 2.0 variants, but its still SAML 2.0 communication)unspecified format for parsing SAMLSubject NameID.
Link for ACS is https://:5601/_opendistro/_security/saml/acs
Also mapping username-username, and constant attribute roles tried with “all_access” and “*”.

Everything seemed ok regarding configuration, rechecked couple of times with SAML Opendistro instruction for configuration, however still receiving this kind of URL (https://:5601/customerror?type=samlAuthError#?_g=()), and having no logs explaining the issue in both Kibana or Elasticsearch.
Also added respective lines in log4j2.properties in Elasticsearch (https://opendistro.github.io/for-elasticsearch-docs/docs/troubleshoot/saml/#inspect-the-saml-response), which generates no additional log.

If anyone has an idea what can be more looked into, please advice. I can add additional information if necessary.
Opendistro version is 1.4.0, and ELK version is 7.4.2.

Hi,

have your tried it without roles?

Delete or comment line

roles_key: roles

and add your username to role mapping all_access in roles_mapping.yml.

I can get it to work like this but not with roles. see SAML/Okta login to Kibana not working with roles.

Regards
Clifford

Hi Clifford,

I have tried the way you suggested, looked at your thread also, removed roles, added my user to roles, copied the part regarding logging for SAML/Authentication, and I got response like this:

[2020-05-13T03:36:40,630][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Rest authentication request from <KIBANA INTERNAL IP>:52340 [original: /<KIBANA INTERNAL IP>:52340]
[2020-05-13T03:36:40,630][DEBUG][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Check authdomain for rest internal/0 or 2 in total
[2020-05-13T03:36:40,630][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Try to extract auth creds from basic http authenticator
[2020-05-13T03:36:40,630][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] No 'Authorization' header, send 403
[2020-05-13T03:36:40,630][DEBUG][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Check authdomain for rest noop/1 or 2 in total
[2020-05-13T03:36:40,630][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Try to extract auth creds from saml http authenticator
[2020-05-13T03:36:40,656][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] No 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

I had another look at your configuration and

entity_id: https://<KIBANA IP>

seems wrong. It most likely contains the domain of the IdP and a hash. Have a look in your elastic-metadata-jumpcloud.xml

Regards
Clifford

That shouldn`t be an issue.
According to Jumpcloud explanation it is:

(Required) This is the unique, case-sensitive identifier used by JumpCloud for this service provider. Please ensure that the value you enter matches the Identity Provider Entity ID you configured on your service provider’s SSO configuration page.

However, I have changed it on both Jumpcloud and Opendistro side to ‘jc-kibana-prod’, updated metadata.xml file, ran security script, and still have same output:

[2020-05-13T13:00:14,906][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Rest authentication request from <KIBANA IP>:54232 [original: /<KIBANA IP>:54232]
[2020-05-13T13:00:14,906][DEBUG][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Check authdomain for rest internal/0 or 2 in total
[2020-05-13T13:00:14,907][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Try to extract auth creds from basic http authenticator
[2020-05-13T13:00:14,907][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] No 'Authorization' header, send 403
[2020-05-13T13:00:14,907][DEBUG][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Check authdomain for rest noop/1 or 2 in total
[2020-05-13T13:00:14,907][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] Try to extract auth creds from saml http authenticator
[2020-05-13T13:00:14,939][TRACE][c.a.o.s.a.BackendRegistry] [phx-dsctes0.bmc.phoenixnap-internal.com] No 'Authorization' header, send 401 and 'WWW-Authenticate Basic'

One question though, our cluster has 3 ES nodes, I make updates on first ones config.yml, and than run security script. Do you know, its that common approach, or config files should be same on all 3 nodes?

The security security script writes the configuration to an index and the two other nodes reload from there. So the configuration files on the nodes don’t have to be the same.

Regards
Clifford

Have you already had a look at the response from Jumpcloud posted to Kibana after login? Maybe that gives a hint?

Regards
Clifford

Nope, I can paste response here, only hiding sensitive data, however in this particular request, I was trying with parsing roles:

<saml2p:Response
	xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
	Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
	Destination="https:// <KIBANA_PUBLIC_IP> :5601/_opendistro/_security/saml/acs"
	ID="IRCRI9SNTW44R87FGMOLT7NQSOHRGQZC1QNXDEXV"
	InResponseTo="ONELOGIN_6bbb1ea5-c2d1-4008-931f-8dda6a54fae3"
	IssueInstant="2020-05-13T21:31:02.404Z"
	Version="2.0">
	<saml2:Issuer
		xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
		Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">jc-kibana-prod</saml2:Issuer>
	<saml2:Issuer
		Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">jc-kibana-prod</saml2:Issuer>
	<saml2p:Status>
		<saml2p:StatusCode
			Value="urn:oasis:names:tc:SAML:2.0:status:Success">
		</saml2p:StatusCode>
	</saml2p:Status>
	<saml2:Assertion
		xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
		xmlns:xs="http://www.w3.org/2001/XMLSchema"
		ID="JTAE75G39HYUESS6VF0G9AXLGXTN6MYE07YYGWB9"
		IssueInstant="2020-05-13T21:31:02.404Z"
		Version="2.0">
		<saml2:Issuer
			Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">jc-kibana-prod</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:CanonicalizationMethod>
				<ds:SignatureMethod
					Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256">
				</ds:SignatureMethod>
				<ds:Reference
					URI="#JTAE75G39HYUESS6VF0G9AXLGXTN6MYE07YYGWB9">
					<ds:Transforms>
						<ds:Transform
							Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature">
						</ds:Transform>
						<ds:Transform
							Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
							<ec:InclusiveNamespaces
								xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
								PrefixList="xs">
							</ec:InclusiveNamespaces>
						</ds:Transform>
					</ds:Transforms>
					<ds:DigestMethod
						Algorithm="http://www.w3.org/2001/04/xmlenc#sha256">
					</ds:DigestMethod>
					<ds:DigestValue>0mnGbE4f3wkHAJM6yhqckbcoMfgI8CQiKVRruoVKmQY=</ds:DigestValue>
				</ds:Reference>
			</ds:SignedInfo>
			<ds:SignatureValue> <SIGNATURE_VALUE_HERE> </ds:SignatureValue>
			<ds:KeyInfo>
				<ds:X509Data>
					<ds:X509Certificate> <CERTIFICATE_HERE> </ds:X509Certificate>
				</ds:X509Data>
			</ds:KeyInfo>
		</ds:Signature>
		<saml2:Subject>
			<saml2:NameID
				Format="urn:oasis:names:tc:SAML:1.0:nameid-format:unspecified"> <MY_USERNAME> </saml2:NameID>
			<saml2:SubjectConfirmation
				Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
				<saml2:SubjectConfirmationData
					InResponseTo="ONELOGIN_6bbb1ea5-c2d1-4008-931f-8dda6a54fae3"
					NotOnOrAfter="2020-05-13T21:36:02.404Z"
					Recipient="https:// <KIBANA_PUBLIC_IP> :5601/_opendistro/_security/saml/acs">
				</saml2:SubjectConfirmationData>
			</saml2:SubjectConfirmation>
		</saml2:Subject>
		<saml2:Conditions
			NotBefore="2020-05-13T21:26:02.404Z"
			NotOnOrAfter="2020-05-13T21:36:02.404Z">
			<saml2:AudienceRestriction>
				<saml2:Audience>kibana-saml</saml2:Audience>
			</saml2:AudienceRestriction>
		</saml2:Conditions>
		<saml2:AttributeStatement>
			<saml2:Attribute
				Name="roles">
				<saml2:AttributeValue
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
					xsi:type="xs:string">all_access</saml2:AttributeValue>
			</saml2:Attribute>
			<saml2:Attribute
				Name="memberOf"
				NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
				<saml2:AttributeValue
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
					xsi:type="xs:string">app_kibana</saml2:AttributeValue>
			</saml2:Attribute>
			<saml2:Attribute
				Name="username"
				NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
				<saml2:AttributeValue
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
					xsi:type="xs:string"> <MY_USERNAME> </saml2:AttributeValue>
			</saml2:Attribute>
		</saml2:AttributeStatement>
		<saml2:AuthnStatement
			AuthnInstant="2020-05-13T21:31:02.404Z"
			SessionIndex="049f5803-1e03-40b0-8900-02c3c181a800">
			<saml2:AuthnContext>
				<saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>
			</saml2:AuthnContext>
		</saml2:AuthnStatement>
	</saml2:Assertion>
</saml2p:Response>

I’m running out of ideas now. Sorry

Regards
Clifford

Me neither, I am hoping someone from Opendistro and Jumpcloud to jump in to see what can be an issue.