Elasticsearch: Automatic mapping of SAML IDP groups to Elasticsearch roles

Created on 12 Dec 2018  路  5Comments  路  Source: elastic/elasticsearch

Currently, to start using SAML authentication realm it is important to explicitly specify role-mappings for the realm and then maintain it basically in two places (IDP provider and ES (no UI?)). This is the requirement that is simple to forget.

This can be simplified by allowing users to configure Elasticsearch to automatically map IDP groups to its roles. By default, it can be disabled and enabled by explicitly specifying a parameter in the realm settings.

As a possible safety measure, require users to explicitly create a role and assign permissions. Otherwise, log a warning message with the names of groups that cannot be mapped to roles.

cc @jkakavas

:SecuritAuthorization >feature

Most helpful comment

We can discuss when we meet, but I think this is a case for templating role mappings in some way.

We _could_ add a "groups as roles" flag, but I'd prefer to be able to do that in a role mapping, with something like:

{
  "roles": { "template" : { "source" : "{{groups}}" } },
  "rules" : { "field" : { "realm.name" : "saml-cloud" } } }
}

All 5 comments

Some context with regards to

explicitly specify role-mappings for the realm and then maintain it basically in two places (IDP provider and ES

This is not as bad/common as it sounds for mainly two reasons:

  • It's a best practice to handle authorization as close to the data as possible. As such, it's common that that Identity Provider side is the authoritative source for user information (attributes, profile) and the Service Provider is authoritative for authorization decisions. In our case, this means mapping these attributes to Elasticsearch roles and defining what privileges these roles entitle.
  • Most often than not, the Identity Provider and the Service Provider belong in two different security domains. Even if the security domain of the Identity Provider has a notion of RBAC, there is probably no common role definition.

It does make sense to think this through though, in many ways this looks similar to what we allow for LDAP realms with unmapped_groups_as_roles

As a possible safety measure, require users to explicitly create a role and assign permissions. Otherwise, log a warning message with the names of groups that cannot be mapped to roles.

Not sure I follow what you mean here. However you do the role mapping, a role needs to be already defined in Elasticsearch and associated with permissions.

Pinging @elastic/es-security

We can discuss when we meet, but I think this is a case for templating role mappings in some way.

We _could_ add a "groups as roles" flag, but I'd prefer to be able to do that in a role mapping, with something like:

{
  "roles": { "template" : { "source" : "{{groups}}" } },
  "rules" : { "field" : { "realm.name" : "saml-cloud" } } }
}

Agreed! Templated role mappings was my first thought too when I discussed this with @yuri-tceretian

The benefit of the above is that you can then also add every AD user to a role with their own name, which could then be used with a custom role provider.

{
  "roles": { "template" : { "source" : "user__{{username}}" } },
  "rules" : { "field" : { "realm.name" : "ad1" } } }
}
Was this page helpful?
0 / 5 - 0 ratings