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]
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?
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:
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 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
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.