Step by step guide to enable SAML with G Suite Idp (elastic cloud)

Elastic Stack Kibana
1

Hey,

I've spent the last couple hours trying to figure out how to configure Kibana to play along with SAML and G Suite Idp (Google).

I couldn't find any guides so I added all my notes to this gist: https://gist.github.com/m1keil/71d2212c2657b32d086a3309d7e1dd59

Hopefully it will help someone out one day.

3 Likes
2

Thank you so much @m1keil !

Quick question, have you more information regarding the attributes.groups usage and mapping ?

I am part of a group in GSuite and I tried to setup a role mapping rule in Kibana / ES and it doesn't seems to work...
Do you know if it is case sensitive ?

Doc:

"roles" : [  "kibana_user" ],
"rules" : {
      "all" : [
        { "field" : { "realm.name" : "samlid" }}
      ]
    },

"roles" : [  "superuser" ],
"rules" : {
      "all" : [
        { "field" : { "realm.name" : "samlid" }},
        { "field" : { "groups" : "GroupNameWithCaseAsItStateInGSuite" }}
      ]
    },

When I login thanks to SSO, it seems that I get the role kibana_user.
By the way do you know how to check which role do we have during a web session ?

Thk again !

3

You need to configure the Google IDP to send your groups as SAML Attributes , see for example : Set up your own custom SAML app - Google Workspace Admin Help .
Then you need to configure elasticsearch to read these attribute values from the SAML Responses and map them to the internal elasticsearch user property that is named groups , you can read all about it in Configure Elasticsearch for SAML authentication | Elasticsearch Guide [7.6] | Elastic.
Then you would be able to use the values in role mappings in elasticsearch as you tried above with { "field" : { "groups" : "GroupNameWithCaseAsItStateInGSuite" }}

By the way do you know how to check which role do we have during a web session ?

You can make a call to the _authenticate API

4

Hi @ikakavas,

Thanks, I have already read the links you shared :slight_smile:

Regarding GSuite SAML setup, are you referring the step 14 ?
This is exactly what I am not sure about. The attributes names displayed are nothing familiar.

Under the category "Employee Details" I have

  • Job Title
  • Departement
  • Cost Center

Nothing like "group"

I am also trying to achieve the same setup with an other tool.
While doing so, I stumbled uppon https://coreos.com/tectonic/docs/latest/admin/g-suite-saml.html

I will try once again with your advices, but it is really painful to have to do a 2 ways mapping ...

5

Ok so here is my last setup and its results

GSuite

IDP
-----
NameID  | BasicInformation | PrimaryEmail
NameID Format | EMAIL

Mapping
-----------
groups | EmployeDetails | Departement

ES

xpack.security.authc.realms.saml.samlid:
    order: 2
    attributes.principal: "nameid" 
    attributes.groups: "groups" 
    idp.metadata.path: "https://s3.eu-central-1.amazonaws.com/BUCKET_NAME/google-saml/metadata.xml" 
    idp.entity_id: "https://accounts.google.com/o/saml2?idpid=XXXXX" 
    sp.entity_id: "https://YYYY-central-1.aws.cloud.es.io:9243/" 
    sp.acs: "https://YYYY-central-1.aws.cloud.es.io:9243/api/security/v1/saml"
    sp.logout: "https://YYYY-central-1.aws.cloud.es.io:9243/logout"

Role_mapping

{
  "gsuite_to_kibana" : {
    "enabled" : true,
    "roles" : [
      "kibana_readonly"
    ],
    "rules" : {
      "all" : [
        {
          "field" : {
            "realm.name" : "samlid"
          }
        }
      ]
    },
    "metadata" : {
      "version" : 1
    }
  },
  "gsuite_to_admin" : {
    "enabled" : true,
    "roles" : [
      "superuser"
    ],
    "rules" : {
      "all" : [
        {
          "field" : {
            "realm.name" : "samlid"
          }
        },
        {
          "field" : {
            "groups" : "Devops"
          }
        }
      ]
    },
    "metadata" : {
      "version" : 1
    }
  }
}

Results
-> Login works
-> But not groups

GET /_security/_authenticate

{
  "username" : "first.last@example.com",
  "roles" : [
    "kibana_readonly"
  ],
  "full_name" : null,
  "email" : null,
  "metadata" : {
    "saml_nameid" : "first.last@example.com",
    "saml_nameid_format" : "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
    "saml(groups)" : [ ]     <--------- WHY ????
  },
  "enabled" : true,
  "authentication_realm" : {
    "name" : "samlid",
    "type" : "saml"
  },
  "lookup_realm" : {
    "name" : "samlid",
    "type" : "saml"
  }
}

PS: Unfortunately for the moment I have no access to the ES logs... My ES cloud deployment seems to have an issue to display them.

6

Not really sure if I follow what you are saying. I will attempt a clarifying comment with an example as I can understand this might sound counter intuitive if you aren't used to how SAML expects things to happen.

Let's say your end goal is to have everyone in the Google Department "MyDepartment" to have read privileges over an index called "my-index".

Google Side

You need to configure Google to send this value as a SAML Attribute. I don';t have access to a Google based IDP but I guess the simplest thing to do is to add a row reading:

department               Employee Details                     Department

in the Attribute Mapping section of GSuite IDP. This will tell Google to send a SAML Attribute in the SAML Response that will look like

<saml:Attribute Name="department" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
        <saml:AttributeValue xsi:type="xs:string">MyDepartment</saml:AttributeValue>
</saml:Attribute>

Elasticsearch Side

You need to configure elasticsearch to parse that information and use it

  1. By configuring

     attributes.groups: department

    in the SAML realm configuration, you tell elasticsearch to find the SAML Attribute with name department in the SAML Response and take its values and add them to the Elasticsearch user groups property. So after authentication your elasticsearch authenticated user will have a user property named groups with value MyDepartment

  2. You need to configure a role to give read access to your my-index index . I..e

     POST /_security/role/example_role
 {
    "indices": [
     {
       "names": [ "my-index"],
       "privileges": ["read"]
     }
   ]
 }

  3. Finally you need to configure the role mapping that will give this role to your SAML users that are in the correct department:

    POST /_security/role_mapping/mapping1
{
 "roles" : [
   "example_role"
 ],
 "rules" : {
   "all" : [
     {
       "field" : {
         "realm.name" : "samlid"
       }
     },
     {
       "field" : {
         "groups" : "MyDepartment"
       }
     }
   ]
 }
}
7

Ok, looks like we have a common understanding of what needs to happen :slight_smile:

No clue, based on the configuration you shared above:

Mapping
-----------
groups | EmployeDetails | Departement

I assume that the user with which you authenticate is in no Department. That issue seems to be on the GSuite side though...

8

Hi @ikakavas,

You are totally right, the issue is now on GSuite setup.

Anyway, big thanks for helping me to better understand how all that thing works :slight_smile:

9

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