Kibana SAML implementation issues

(Constantine Abayeu) #1

We are having some issues configuring SAML on our elastic 6.4 cluster

I am getting the following error, when trying to get to kibana at a given port:

[2018-09-04T13:41:42,003][WARN ][r.suppressed             ] path: /_xpack/security/saml/prepare, params: {} org.elasticsearch.ElasticsearchSecurityException: Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=null, assertionConsumerServiceURL=}]

we are using ADFS for IDP and have added our entity ID to it with this XML:

<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="">
  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location=""/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="" index="1" isDefault="true"/>
    <md:AttributeConsumingService index="1" isDefault="true">
      <md:ServiceName xml:lang="en-US">esxb</md:ServiceName>
      <md:RequestedAttribute FriendlyName="SamAccountName" Name="nameid:persistent" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>

this is what in our elasticsearch.yml
        type: saml
        order: 0
        idp.metadata.path: ""
        idp.entity_id: ""
        sp.entity_id: ""
        sp.acs: ""
        sp.logout: ""
        attributes.principal: "nameid:persistent"

and this is what in our Kibana config:

server.port: 5601

<... obfuscated part... - due to having some IDs here and passwords> [saml]
server.xsrf.whitelist: [/api/security/v1/saml]

(Brandon Kobel) #2

Hey @Constantine_Abayeu, is Kibana hosted behind a reverse-proxy? If it is, you'll want to set the settings specified here.

If you aren't using a reverse-proxy, you can set the following as well in your kibana.yml:

(Constantine Abayeu) #3

Hi @Brandon_Kobel!
there is no reverse-proxy in this scenario.

I have tried setting to the and now it is reflecting in the error message, but the message is still the same:

[2018-09-04T15:28:44,516][WARN ][r.suppressed             ] path: /_xpack/security/saml/prepare, params: {}
org.elasticsearch.ElasticsearchSecurityException: Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=null, assertionConsumerServiceURL=}]

I am also getting similar error when I am doing that to another client, where I do not have saml set up. and if I reach out to /_xpack/security/saml/prepare with an empty body...

why would it be sending an empty body to a POST endpoint?

(Brandon Kobel) #4

Hey @Constantine_Abayeu, your identity provider is looking for an ACS of but you have the following in your elasticsearch.yml:
        sp.acs: ""

If your Kibana is accessible on port 5601, and you aren't using a reverse-proxy, you'll want to set:
        sp.acs: ""

(Constantine Abayeu) #5

YES! this did work! Thank you! - I am now greeted with an ADFS login screen (it has some issues, since I probably defined my elastic entity incorrectly on that end. but as far as Kibana goes that was it!)

Thanks a ton for your help!

(Brandon Kobel) #6

Awesome, glad to hear that worked @Constantine_Abayeu!

(Constantine Abayeu) #7

Thanks a lot for your help!
I have another question that is further down the line in this @Brandon_Kobel .

I was able to modify my trust on adfs side to give me back sAMAccountName and memberOf as parameters in my request. And changed attributes.principal to be "sAMAccountName". It now authenticates just fine.
However inside Kibana i see nothing but the menu on the left.

I have attributes.groups set to "memberOf" and it is still the same.

Group mappings are done mapping the samaccountname to group DN. which is what memberOf is a list of.

it comes out something like: [sAMAccountName=[MY_ID], memberOf=[CN=Group Name1,OU=My Ou Name,DC=company,DC=com, CN=Group Name2,OU=My Ou Name,DC=company,DC=com] ] something along those lines

(Constantine Abayeu) #8

Is the username in elasticsearch case sensitive? - if so that would explain things.

(Tim Vernum) #9

The answer isn't quite as simple as the question sounds. It depends very much on the context in which you are using it.

Is this with respect to role-mappings?
If so, then yes, something like

"field": {
  "username": "my_id"

is case sensitive.

But it's not that usernames are case sensitive, per se, it's that the expressions in role mappings are case sensitive (*)

(*) Except for the dn and groups fields, if they contain a value that can be parsed as a Distinguished Name, then we will attempt to match according to DN matching rules (which are not case sensitive) rather than simply doing string comparisons.

(Constantine Abayeu) #11

for anyone wondering, here is how the ADFS trust was set up with an f5vip in front of elastic cluster:

<?xml version="1.0" encoding="UTF-8"?><md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" entityID="REPLACE_URL">
  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="REPLACE_URL:443/logout"/>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="REPLACE_UR:443/api/security/v1/saml" index="1" isDefault="true"/>
    <md:AttributeConsumingService index="1" isDefault="true">
      <md:ServiceName xml:lang="en-US">elastic</md:ServiceName>
      <md:RequestedAttribute FriendlyName="principal" Name="nameid:persistent" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/>

(system) #12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.