Elastic Cloud Kibana SAML Okta not working with groups

Elastic Stack Kibana
1

Hello,

I have setup ES and Kibana to use xpack, and have got it all working. When I create the kibana users like so

{
   "enabled": true,
    "roles": [ "kibana_user" ], 
    "rules": { 
        "field": { "realm.name": "cloud-saml" } 
    },
    "metadata": { "version": 1 }
}

I can login via Okta with my user ghardy and I have read access.

However, when I create the superuser based on groups using the following

{
   "enabled": true,
    "roles": [ "superuser" ], 
    "rules": { "all" : [ 
        { "field": { "realm.name": "cloud-saml" } }, 
        { "field": { "groups": "elasticadmins" } }
    ]},
    "metadata": { "version": 1 }
}

I keep getting user ghardy is unauthorised. In my Okta I have create the elasticadmins group, and assigned my user to that group. I am just lost to why it doesn't seem to be putting my user as a superuser.

kibana.xml

xpack.security.authProviders: [saml, basic]
server.xsrf.whitelist: [/api/security/v1/saml]
xpack.security.public:
  protocol: https
  hostname: <url>.eu-west-1.aws.found.io
  port: 9243

elasticsearch.yml

  security:
    authc:
      realms:
        cloud-saml: 
          type: saml
          order: 2
          attributes.principal: "nameid:persistent" 
          attributes.groups: "groups" 
          idp.metadata.path: "https://<url>.okta.com/app/<id>/sso/saml/metadata" 
          idp.entity_id: "http://www.okta.com/<id>" 
          sp.entity_id: "https://<url>.eu-west-1.aws.found.io:9243/" 
          sp.acs: "https://<url>.eu-west-1.aws.found.io:9243/api/security/v1/saml"
          sp.logout: "https://<url>.eu-west-1.aws.found.io:9243/logout"

Let me know if I am missing anything that you need
Any help will be great, Thank you!

2

Hi Gavin,

Nit picking here but so that we're on the same page: This is a role mapping rule and what it does is that it assigns roles ( kibana_user ) in this case, to users that have authenticated via the SAML realm with name cloud-saml . You are not sharing how you are creating those, but keep in mind that different role mappings need to have different names ( part of the URI when you send the request to Elasticsearch ) , otherwise you are overwriting the existing ones with the new ones.

Your configuration looks good to me and matches what I've seen being required integrating with Okta. My guess is that either:

  • Okta is not configured to send the group membership attribute
  • Okta is configured to send the group membership attribute but the attribute name is not groups (as your configuration implies)
  • Okta is configured to send the group membership attribute, and its name is groups, but your user ( ghardy) is not member of that group.

I would suggest that you

  • Check your Okta configuration to verify that the group membership attribute is named group and is also sent in the SAML Responses ( IIRC the section in Okta is named "Group Attribute Statements" )

  • When the first role mapping is assigned, and you can login to Kibana, go to the Dev Tools section and execute the following query:

    GET /_security/_authenticate

    This would show you roles that your user is currently assigned, but also all the SAML attributes that were sent from Okta for your user, under the "metadata" section of the response. This will show you if the group membership is sent from Okta, under which attribute name and with which value.

3

Hi Ioannis, thank you for your reply.

Are you saying that attributes.groups: "groups" in my elasticsearch.yml tat "groups" should match a group in my Okta, so if I have a Devops group, this should be "Devops"?

4

When I run GET /_security/_authenticate my user only has the kibana_user role, it has not been given the superuser role.

5

This is what authenticate brings back when I log in to kibana with my user ghardy

  "username" : "ghardy",
  "roles" : [
    "kibana_user"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "saml_nameid" : "ghardy",
    "saml_nameid_format" : "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
  },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "cloud-saml",
    "type" : "saml"
  },
  "lookup_realm" : {
    "name" : "cloud-saml",
    "type" : "saml"
  }
}
6

Hey, I got it working thanks, turns out it was Okta side!. Thank you again for your help!

7

Are you saying that attributes.groups: "groups" in my elasticsearch.yml tat "groups" should match a group in my Okta, so if I have a Devops group, this should be "Devops" ?

No, not exactly. In attributes.groups: "groups" in your elasticsearch.yml, "groups" should match the name of the attribute in Okta, not its value. That was correctly configured from the start.

That part in the response shows that okta was not sending any group information to elasticsearch ( otherwise you would see it here along with the nameid in the metadata ) and this is why your role mapping was not working.

Glad you figured it out!

8

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