Elastic Cloud Deployment on AWS & SAML Okta

[michal.adamkiewicz (michal)]

Hello guys,
I'm writing because I have been struggling with set up Elastic and OKTA SAML together. To be short and precisely describe my issue (and also help eventually anyone share advice about that - thanks in advance!:):

1. Deployment is done on Elastic Cloud hosted in AWS.
2. Version of stack 7.91.
3. I was following exactly this doc: https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html
4. Below is a snipped that I paste into (edited) "Data" elasticsearch configuration:

 xpack:
  security:
    authc:
      realms:
        saml: 
          okta: 
            order: 2 
            attributes.principal: "nameid:persistent" 
            attributes.groups: "groups" 
            idp.metadata.path: "https://urlToOurOwnOktaDeploymentWithXMLMetadata" 
            idp.entity_id: "http://www.okta.com/someID" 
            sp.entity_id: "https://myKibanaUrl:9243/" 
            sp.acs: "https://myKibanaUrl:9243/api/security/v1/saml"
            sp.logout: "https://myKibanaUrl:9243/logout"

5. I three-times checked all necessary entities ID from point 4. I can be sure 100% that links/IDs are correct.
6. After that I pasted (edited) Kibana configuration section:

xpack.security.authc.providers:
  saml.saml1:
    order: 0
    realm: okta
    description: "Log in using my own SAML" 

7. At the very end, accordingly to documentation I made a role-mapping object, like below:

POST /_security/role_mapping/CLOUD_SAML_TO_KIBANA_ADMIN 
{
   "enabled": true,
    "roles": [ "kibana_admin" ], 
    "rules": { 
        "field": { "realm.name": "okta" } 
    },
    "metadata": { "version": 1 }
}

8. Those 3 changes are everything I made on Elastic. Of course on OKTA side application has been created and I followed "standard pattern", without any custom modifications and adding custom parameters and so on.

9. Final point was to test it. But unfortunately I received 401 error code with message:

   Unauthorized,
   "[security_exception] unable to authenticate user [] for action [cluster:admin/xpack/security/saml/authenticate], with {header={ WWW-Authenticate= { 0="Bearer realm=\"security\"" & 1="ApiKey" & 2="Basic realm=\"security\" charset=\"UTF-8\"" } } }"

Any idea would be really supper appreciated as I completely lost clue where I can find any log or tip about next steps.

[ikakavas (Ioannis Kakavas)]

I believe you have edited the message to remove the <unauthenticated-saml-user> from the "authenticate user " part, is that correct? . See https://www.elastic.co/guide/en/elasticsearch/reference/current/trb-security-saml.html, point 4.

In short, there is some misconfiguration that doesn't allow us to authenticate the user that you attempt to login with and the reason for that would be printed in the elasticsearch logs. Take a look at the logs , they will contain the necessary information to help you move forward.

If I had to take a wild guess, I'd say that you haven't configured Okta to release a NameID with persistent format and as such we can't create a principal for the user in elasticsearch, and as such fail the authentication

[michal.adamkiewicz (michal)]

@ikakavas

First of all thank you soo much for your input and time!
About "msg" that's right, apologize, somewhat I has been eaten

. This time to be 100% sure that we are about the same - I attached this error message.

Regarding logs - can I ask you for a piece of advice, where exactly I would be able to look for this? (it's not self-maintained instance, instead it's your Cloud edition based on AWS in this case).

And lastly... your thoughts are very similar to my suspicions! - as I'm not responsible for OKTA deployment - I can only forward info to a team, but unfortunately I'm not able to implement that by myself. But that's mean that default methodology (aka...next, next, next :D) will not work by default I guess? Elastic is waiting for some field, that has to be correctly set up on OKTA side right?

Once again, thank you so much! I believe, it's already seems to be a lifesaver!

[ikakavas (Ioannis Kakavas)]

@michal.adamkiewicz

Regarding logs - can I ask you for a piece of advice, where exactly I would be able to look for this? (it's not self-maintained instance, instead it's your Cloud edition based on AWS in this case).

In Elastic Cloud, you can go to Logs and metrics under your Deployment and you can see your logs there.

@michal.adamkiewicz

But that's mean that default methodology (aka...next, next, next :D) will not work by default I guess

I'm not entirely sure if Okta adds a NameID with format persistent by default, or what attributes you get sent by default from an Okta SAML app. Your Okta team would probably need to send you that info ( a screenshot from the Okta SAML app would be sufficient for you I'd guess ) and then you can decide what your attributes.principal: should be ( a NameID or a SAML Attribute ) . This specific part of our docs might be very helpful too for the benefit of your understanding.

Cheers

[michal.adamkiewicz (michal)]

Issues solved!.

Thanks to your suggestion about NameID format!.
It turned out that we had:

<md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat>

where it should be:

<md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat>

Thank you very very much for your effort.
@ikakavas

This forum rocks, as well as your products!