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

@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.

Throwing in another update I think might be relevant, Kibana configs changed a bit too, for a 8.10+ elastic cloud deployment this seems to do the job:

xpack.security.authc.providers:
  saml.gsuite:
    order: 0
    realm: gsuite
    description: "Log in with Google"
  basic.basic1:
    order: 1