Configure Kibana to use SAML with Google Workspace (Google Apps, G Suite)

README.md

The following worked with Elastic Cloud, Elasticsearch & Kibana v7.6.0. It should be pretty close for other kinds of deployments. Before starting, make sure you have the right license level that allows SAML.

Create SAML App in Google Workspace:

• Navigate to the SAML apps section of the admin console

• Click the Add button and choose to "Add custom SAML app"

• Write down the Entity ID and download the Idp metadata file

• Choose application name, description and add logo

• In the "Service Provider Details" screen add the following:

  • ACS URL: https://<kibana url>:9243/api/security/v1/saml
  • Entity ID: https://<kibana url>:9243/
  • Start URL: https://<kibana url>:9243/
  • Name ID: Basic Information | Primary Email
  • Name ID Format: Email

• Skip attribute mapping and click "Finished"

• Enable SAML app to be in "On for everyone" status

Create and upload the metadata bundle:

• Rename the metadata file to metadata.xml

• Place the file in folder named saml

• Compress the folder into zip file.

• Navigate to the custom plugins section under your Elastic account

• Add a new plugin:

  • Plugin name: <whatever you like, e.g gsuite-saml>
  • Version: *
  • Description: <whatever you like>

• Upload the zip file created above

Configure Kibana's role mapping

• In Kibana navigate to: Managment -> Security -> Role mappings

• Create a new role mapping:

  • Roles: Whatever roles you need
  • Add the following mapping rule:
    • User filed: realm.name
    • Type: text
    • Value: <realm name from elasticsearch.yml. e.g gsuite>

Configure Elasticsearch and Kibana

• Under the Elasticsearch deployment configuration go Edit screen
• Enable the gsuite-saml plugin under "Elasticsearch plugins and settings"
• Paste the content of elasticsearch.yml to "User setting overrides" in the Elasticsearch section
• Paste the content of kibana.yml to "User setting overrides" in the Kibana section
• Click Save and wait for the re-deloyment to finish successfully

If everything went smooth, you should be able to point your browser to Kibana and get authenticated with your Google account.

Reference

• https://www.elastic.co/guide/en/cloud/current/ec-securing-clusters-SAML.html
• https://www.elastic.co/guide/en/cloud/current/ec-custom-bundles.html

elasticsearch.yml

# make sure to adjust values accordingally before pasting.
# the "gsuite" key is arbitrary. you can choose whatever name you like.
# you'll need to use it in kibana.yml as the value for "xpack.security.authc.saml.realm" 
# and in the role mapping rules

xpack.security.authc.realms.saml.gsuite: 
  order: 2
  attributes.principal: "nameid" 
  attributes.groups: "groups" 
  idp.metadata.path: "/app/config/saml/metadata.xml" 
  idp.entity_id: "https://accounts.google.com/o/saml2?idpid=XXXXXXXXX <Entity id from Google Workspace>" 
  sp.entity_id: "https://<kibana url>:9243/" 
  sp.acs: "https://<kibana url>:9243/api/security/v1/saml"
  sp.logout: "https://<kibana url>:9243/logout"

kibana.yml

# this enables both saml and basic (built in) auth.
# to use basic auth while saml is on, use https://<kibana url>:9243/login
# you might need to clear cache/cookies or use incognito

xpack.security.authc.providers: [saml,basic]
server.xsrf.whitelist: [/api/security/v1/saml]
xpack.security.authc.saml.realm: gsuite

Thank you for providing this. It is very helpful. We would not have figured it out without your help. We got it working after a few attempts. Here are some additional tips:

Tip #1
It was not clear what "step 1" was since the steps are not numbered. There are two entity IDs in the first section of steps. One is the kibana url and the other is from the gsuite saml app. The below line in the elastic.yml file needs the entity id from the gsuite saml app not the one that is the kibana url.

idp.entity_id: "https://accounts.google.com/o/saml2?idpid=XXXXXXXXX <Entity id from step 1>"

Tip #2
We had two data configurations and a ML configuration. We needed to place the elastic.yml lines in all three locations.

Glad to hear it helped. Will update accordingly.

@m1keil Thanks for guide 👍
One thing is not working for me:

Enable the gsuite-saml plugin under "Elasticsearch plugins and settings"

I'm not able to view the extension bundle on the section with plugins 🤔

UPDATE:
I figured it out, during the extension bundle configuration, version should match ES, so * is a good option ;).

Ok looks like it was the bundle though i created a zip file with

saml/metadata.xml

Not sure why it would not of worked.

We were able to build off of this and create more granular rbac within kibana using saml integrated accounts. Sharing here for others benefit.

All steps fall within the Configure Kibana's role mapping section of this guide.

1. Confirm the All are true setting is set at the very top (above the realm.name rule created in this section)
2. Add another mapping rule using the + Add link and select Add rule group
3. Set the rule group to Any are true
4. Create a rule in the group for a user who need the elastic role this role mapping applies. User field = username; type = text; Value = user ID (their gsuite email)
5. Create another rule in the group for each additional use who needs the role this rule mapping applies. Click the small blue + sign next to the first rule created in this group to add more rules to this group.

These prior steps above have more narrowly defined who will get the role mapping in your first role mapping. Before, that role would apply to any and all gsuite saml integrated users.

To create a different role mapped to gsuite saml integrated users:

1. Create a new role mapping
2. Give it a name that aligns with the role you are mapping and to who you are mapping it to
3. Enable mapping
4. Specify the role you want to map for these users (this should be a different role than the one in your original role mapping)
5. Create mapping rules like you did for the first rule mapping (combining the original instructions in this git with the added steps above)

Clear browser history and open a new browser session to test.

This approach works, but it maps elastic roles to specific gsuite users. It would be more ideal to map elastic roles to groups in gsuite, but we could not get that to work. If others know how to do that, we would appreciate the guidance. We tried using the <group_name> by itself and with the @<domain_name>.com appended to it. Neither worked

@threatangler-jp I experienced the same, unable to mapping gsuite groups into elastic roles.

Hi @m1keil, @wgebis and @threatangler-jp

Firstly thanks for your notes here - this has been very helpful in getting our ES clusters set up for SAML.

We think we also found why it wont pick up Google groups directly and it seems to be Google, rather than ES. We found this article about setting up SAML with GSuite that states:

By default, GSuite doesn't offer a way to send user groups through SAML.

We played around with the schemas (as that documentation describes) and could make it work as the ES documentation suggests. Bit of a hassle having to effectively reset up your groups in GSuite for every user though.

Since its our developers we want to give access to, we're ok with superuser for all for now. We're limiting who can access the saml auth in GSuite instead.

Thank you for this helpful guide!

For the benefit of others, we managed to control Kibana permissions using Custom Schema attributes in Gsuite. So basically, setting a specific value in a user's custom attribute will match a Kibana role (via role mapping):

1. First, create a new Custom schema attribute for users in your Gsuite environment (in Gsuite admin console).

2. In your Custom SAML app for Kibana, Include the following SAML attribute mapping (we are controlling different permission sets for different Kibana environments too):
   

3. Add the desired role name in the user's attributes in your Gsuite console:
   

4. In the Kibana Role Mapping, add a second rule:

   • User field: groups
   • Type: text
   • Value: superuser (from the Gsuite user's attribute)

Then you can add multiple role mappings, matching the users' attributes on Gsuite according to the permission set you wish to give. To complement this, we also have a simple python script that periodically checks and updates the users' Kibana SSO attributes for members of a given GSuite group (Tech, business etc.), so adding a user to a Gsuite group would give the required Kibana roles automatically.

The best solution I found was to offer multiple SAML realms, each identical except for the name and entity id (which, to differentiate them, I appended #groupname to each), and to have separate mapping rules for each realm to assign the relevant role. In Google Workspace/GSuite, you then set up these as separate custom SAML apps with the apps enabled for their respective group.

Login screen:

@sirachv your method worked great for us. Thank you for the tip!

Hey, thanks for this very useful gist!

Things have moved on in Elasticsearch land, so the SAML callback URL is no longer valid, as per this. Three places above that need to change.

In the main section Create SAML App in Google Workspace

ACS URL: https://:9243/api/security/v1/saml

should now be

ACS URL: https://:9243/api/security/saml/callback

Similar changes needed in the example elasticsearch.yml and kibana.yml files.

We made a change to our elastic cluster and it came back from the change in a degraded state. We lost access to the warm node, detection rules were failing to run, and we could not close detection rule alerts. Possibly other symptoms but those were what we noticed.

Elastic support says the root cause is the extension from our Google Workspace integration. They did not state why but we removed it and problem solved - but now SSO with google is not in place.

Has anyone else had this experience? Is there possibly a recent change to this configuration that we missed and need to apply?

Dunno if it depends on the Google Workspace subscription or if this is a newer development, but I've been able forward group membership from the Google Workspace IdP to the SP and use it in role mapping directly. The Google Workspace Documentation also seems pretty unequivocal about this:

After having mapped the groups on Google Workspace IdP to an "App attribute" (in our case named google_groups), I've been able to use it successfully for role mapping:

Kibana user settings:

xpack.security.authc.realms.saml.saml1:
  order: 2
  attributes.principal: "nameid" 
  attributes.groups: "google_groups" 
  ...

Role mapping rule:

{
  "all": [
    {
      "field": {
        "realm.name": "saml1"
      }
    },
    {
      "field": {
        "groups": "staff"
      }
    }
  ]
}

@sm3142 This should be the new accepted answer. Managed to set up google group membership as detailed above.