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.
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 !
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
Hi @ikakavas,
Thanks, I have already read the links you shared 
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
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 ...
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.
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".
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>
You need to configure elasticsearch to parse that information and use it
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
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"]
}
]
}
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"
}
}
]
}
}
Ok, looks like we have a common understanding of what needs to happen 
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...
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
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.