Kibana SAML implementation issues

Constantine_Abayeu · September 4, 2018, 7:04pm

Hello,
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=https://0.0.0.0:5601/api/security/v1/saml}]

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="https://SERVER.MYCOMPANY.com:5601">
  <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="https://SERVER.MYCOMPANY.com:50000/logout"/>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://SERVER.MYCOMPANY.com:50000/api/security/v1/saml" 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"/>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

this is what in our elasticsearch.yml

xpack.security.authc.realms.saml:
        type: saml
        order: 0
        idp.metadata.path: "https://sts.MYCOMPANY.com/FederationMetadata/2007-06/FederationMetadata.xml"
        idp.entity_id: "http://sts.MYCOMPANY.com/adfs/services/trust"
        sp.entity_id: "https://SERVER.MYCOMPANY.com"
        sp.acs: "https://SERVER.MYCOMPANY.com:50000/api/security/v1/saml"
        sp.logout: "https://SERVER.MYCOMPANY.com:50000/logout"
        attributes.principal: "nameid:persistent"

and this is what in our Kibana config:

server.port: 5601
server.host: 0.0.0.0

<... obfuscated part... - due to having some IDs here and passwords>

xpack.security.authProviders: [saml]
server.xsrf.whitelist: [/api/security/v1/saml]

Brandon_Kobel · September 4, 2018, 8:02pm

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

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

Constantine_Abayeu · September 4, 2018, 8:36pm

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

I have tried setting server.host to the SERVER.MYCOMPANY.com 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=https://SERVER.COMPANY.com:5601/api/security/v1/saml}]

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 · September 4, 2018, 9:01pm

Hey @Constantine_Abayeu, your identity provider is looking for an ACS of https://SERVER.COMPANY.com:5601/api/security/v1/saml but you have the following in your elasticsearch.yml:

xpack.security.authc.realms.saml:
        ...
        sp.acs: "https://SERVER.MYCOMPANY.com:50000/api/security/v1/saml"
        ...

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

xpack.security.authc.realms.saml:
        ...
        sp.acs: "https://SERVER.MYCOMPANY.com:5601/api/security/v1/saml"
        ...

Constantine_Abayeu · September 4, 2018, 9:05pm

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 · September 4, 2018, 9:50pm

Awesome, glad to hear that worked @Constantine_Abayeu!

Constantine_Abayeu · September 5, 2018, 6:20pm

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 · September 5, 2018, 6:33pm

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

TimV · September 6, 2018, 4:03am

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 · September 12, 2018, 3:57pm

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:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
    <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"/>
    </md:AttributeConsumingService>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

system · October 10, 2018, 3:57pm

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