SAML error with ELK Stack

Elastic Stack Elasticsearch
1

Hi guys,

i am trying to configure Kibana authentication via SAML with oracle IAM stack as an Identity provider.
In elasticsearch log we have:
org.elasticsearch.ElasticsearchSecurityException: Cannot find any matching realm for [SamlPrepareAuthenticationRequest{realmName=null, assertionConsumerServiceURL=https://rp.lab.priv:443/api/security/v1/saml}]
at org.elasticsearch.xpack.security.authc.saml.SamlUtils.samlException(SamlUtils.java:105) ~[?:?]
at org.elasticsearch.xpack.security.action.saml.TransportSamlPrepareAuthenticationAction.doExecute(TransportSamlPrepareAuthenticationAction.java:52) ~[?:?]
at org.elasticsearch.xpack.security.action.saml.TransportSamlPrepareAuthenticationAction.doExecute(TransportSamlPrepareAuthenticationAction.java:33) ~[?:?]
at org.elasticsearch.action.support.TransportAction.doExecute(TransportAction.java:143) ~[elasticsearch-6.5.1.jar:6.5.1]

The elasticsearch yml have these lines:
xpack.security.authc.token.enabled: true
xpack:
security:
authc:
realms:
saml1:
type: saml
order: 2
idp.metadata.path: /etc/elasticsearch/saml/idp_metadata.xml
idp.entity_id: "https://rp.lab.priv/oam/fed"
sp.entity_id: "https://kibana.lab.priv:5601/"
sp.acs: "https://rp.lab.priv/api/security/v1/saml"
sp.logout: "https://rp.lab.priv/logout"
attributes.principal: "urn:oid:0.9.2342.19200300.100.1.1"
attributes.groups: "urn:oid:1.3.6.1.4.1.5923.1.5.1."

The kibana yml file have these lines:
xpack.security.authProviders: [saml, basic]
server.xsrf.whitelist: [/api/security/v1/saml]
xpack.security.public:
protocol: https
hostname: rp.lab.priv
port: 443
I have look in troubleshooting but the sp.acs and kibana public host is the same.
Anyone have a better idea?
Thank you in advance,
Victor

2

These are matched as raw strings - we don't infer identity by parsing port numbers, etc.
So you need the sp.acs setting in Elasticsearch and the ACS URL in Kibana to be byte-for-byte identical.

See the troubleshooting guide for more info.

3

Hi TimV,

Thanks, indeed the 443 added to sp.acs, made me pass this error:

Now i have new one:

[2019-01-18T10:36:48,207][WARN ][o.e.x.s.a.AuthenticationService] [dev-client-01] Authentication to realm saml1 failed - Provided SAML response is not valid for realm saml/saml1 (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response: Code=urn:oasis:names:tc:SAML:2.0:status:Requester Message=null Detail=null])

and saml decoded is:

<?xml version="1.0" encoding="UTF-8"?> 
<saml2p:AuthnRequest 
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" 
AssertionConsumerServiceURL="https://rp.lab.priv:443/api/security/v1/saml" 
Destination="https://rp.lab.priv/oamfed/idp/samlv20" 
ID="_0d6127d26c9d682fff7da4127330feec1d92aa42" 
IssueInstant="2019-01-18T09:36:46.684Z" 
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
Version="2.0">
<saml2:Issuer 
xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">https://kibana.lab.priv:5601/</saml2:Issuer>
<saml2p:NameIDPolicy AllowCreate="false" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</saml2p:AuthnRequest>

Any idea?
should i need to provide to the IdP a user and password to connect to the saml api uri of kibana?

Thanks,
Victor

4

This is covered in the troubleshooting guide - I recommend that you have a read of it.

The short answer is that your IdP didn't like authentication request from Elasticsearch, but is refusing to tell us why. The only thing you can reasonably do is check the IdP logs.

5

Hi,
this i solved also.
But now another question.
If behind RP i publish also the kibana saml url under a general context like /elk/
I have to modify also the
server.xsrf.whitelist: [/api/security/v1/saml]
to
server.xsrf.whitelist: [/elk/api/security/v1/saml] ?
In fact in my saml request towards IDP the assestionconsumerserviceURL="rp.lab.priv:443/api/security/v1/saml" and i need it "rp.lab.priv:443/elk/api/security/v1/saml"
Thank you,
Victor

6

For clarification: Why do you want the ACS url to be "rp.lab.priv:443/elk/api/security/v1/saml" ? If this is because your IdP is configured this way, wouldn't it be preferable to change the IdP configuration instead?

7

Hi,
The root cause is that behind the RP is also the IdP and ELK.
if i am using directly RP URL/app/kibana and RP URL/api/security/ is OK. but i cannot use RP URL/ as for example after SAML login there is a redirect to RP URL/ to select the space to enter in.
So the question is what if behind same RP i have already use the /api context by other application. what i can do then?
Of course the question is if i can use a generic context root like /elk for api, app and spaces URis of Kibana?

Thank you,
Victor

8

Hey @vapetri, you can use server.basePath: /elk and server.rewriteBasePath: true to have all of Kibana's HTTP endpoints behind /elk.

9

Hi Brandon,
is this covering all the resources? /api /app /* ?
or just /app ?

Thank you,
Victor

10

We configured the kibana context root to /elk and now on IdP we have the next error:
<Jan 22, 2019 3:26:52 PM CET> <Error> <oracle.security.fed.controller.web.servlet.FederationServlet> <FEDSTS-12064> <Exception: {0}
oracle.security.fed.event.EventException: java.lang.ClassCastException: java.util.HashSet cannot be cast to java.lang.String

Any ideas?
Thank you,
Victor

11

You'll need to take that up with Oracle. It seems to be a bug in your IdP that we can't do much about.

12

Thank you for your response!

I am working with them to identify the solution.
I will post the solution.
Thank you,

Victor

13

Hi Guys,
i've found the error, which was from SAML version differences between OAM and ELK.
Now i receive:
{"statusCode":400,"error":"Bad Request","message":"Request must contain a kbn-xsrf header."}

In Kibana.yml i have the next values:
server.basePath: "/elk"
server.rewriteBasePath: true
server.xsrf.whitelist: [/elk/api/security/v1/saml]
to inlcude also the new context root.
if i change the value to:
server.basePath: "/elk"
server.rewriteBasePath: true
server.xsrf.whitelist: [/api/security/v1/saml]

i have the elasticsearch error:

[2019-01-25T10:36:30,387][WARN ][o.e.x.s.a.AuthenticationService] [dev-client-01] Authentication to realm saml1 failed - Provided SAML response is not valid for realm saml/saml1 (Caused by ElasticsearchSecurityException[SAML Response is not a 'success' response: Code=urn:oasis:names:tc:SAML:2.0:status:Requester Message=null Detail=null])
and i am redirected to ELK login page.

Also i see in the saml response of Kibana:
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/>

Any ideas?
Thank you,
Victor

14

Hi,

First, as you figured out, you need to set server.xsrf.whitelist: [/api/security/v1/saml] and not server.xsrf.whitelist: [/elk/api/security/v1/saml]

Your Oracle IDP responds with

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"/>

The urn:oasis:names:tc:SAML:2.0:status:Requester signifies that it believes that the problem is the Requester's fault ( The elastic stack is the requester in this context ) and the urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy means that the problem is that it cannot satisfy the request's requirements for the NameID Policy.

Elasticsearch's SAML realm defaults to requesting a transient (urn:oasis:names:tc:SAML:2.0:nameid-format:transient) NameID format but can also be configured explicitly with the nameid_format option as described in our documentation . What you need to do is :

  1. Figure out what kind of NameID format you want to use. See 8.3 and especially 8.3.7 and 8.3.8 in the SAML Core specification
  2. Figure out which formats your SAML IDP supports
  3. Pick one of those and configure both your SAML IDP and your SAML Realm in Elasticsearch accordingly.
15

Hi,
Thanks for the documentation and information.
We use an SAML 1.1 Unspecified format type.
We've just open a ticket at Oracle to see maybe indeed is a bug on their side.

Thank you,
Victor

16

Hi,

The use of urn:oasis:names:tc:SAML:1.1: nameid-format:unspecified is allowed in the SAML 2.0 Core Spec, see section 8.3.1 of the specification I posted above.
If this contains the value you want in order to identify the logged in user or if you can map the attribute.principal to a SAML attribute instead of the NameID, you can adjust the SAML realm configuration in Elasticsearch by setting nameid_format to urn:oasis:names:tc:SAML:1.1: nameid-format:unspecified in your elasticsearch.yml

17

Hi,
Indeed we are using 1.1 version for nameid as supported by Oracle. The principal si directly mapped to Oracle uid - LDAP attribute.
Thanks,
Victor

18

Did you get this working after all ? Setting

nameid_format: "urn:oasis:names:tc:SAML:1.1: nameid-format:unspecified"

should bypass the latest error and then you can get your Elasticsearch user principal mapped by either

attributes.principal: urn:oid:0.9.2342.19200300.100.1.1

or

attributes.principal: nameid

since these two both contain the same value.

19

Hi,
OAM is sending the principal from the LDAP user.uid attribute so this is what we mapped for the user.

Thanks,
Victor

20

Hi,
we manage to make it work with namid in attribute principal.
But now i cannot force the users to be dashboard only and to use only one space for dashboard users only.

If there a role mapping to force users to go to specific space in Kibana?
Can i create another dashboard user role which i can add/inherit to be force via SAML?
this is the role mapping i try to use:
PUT /_xpack/security/role_mapping/Role.AT
{
"roles": [ "Role.AT"],
"enabled": true,
"rules": { "all": [
{ "field": { "realm.name": "saml1" } },
{ "field": { "groups": "Role.AT" } },
{ "field": { "role": "Role.AT" } }
] }
}

Is it enough to use only the groups field to map the SAML Group to ELK role?
If i enter with a local user with the same role, the user is using only one space.
If i come via SAML i am redirect to space default.

Thank you,
Victor