I would like to use this feature to put logic around which roles a given SSO realm is allowed to assign (so the examplemoustache template {{#json}}groups{{/json}}, which is used by default for elastic cloud logon, would be fine except i want to have a whitelist and prefix-based filter of the groups).
I have not been able to find any documentation about this feature, however. Does anyone know (a) which parameters are available in a painless script in the role mapping context and (b) what is the script supposed to return in this context?
Thanks Tim. Yes, the Kibana interface does say "painless or mustache script", but mustache has very limited "scriptability" - they pride themselves on being "logic-less templates". But I will accept that Painless is not officially supported for this purpose and so avoid it.
An alternative approach to this is to perform prefixing on the roles based on the realm using a Mustache template like [{{#groups}}"myprefix-{{.}}",{{/groups}}]. Unfortunately, it only almost works, because this isn't valid JSON: There's a trailing comma. Perhaps that's for another topic, but do you know of a way to handle this with Mustache in Elasticsearch?
Right, the screenshot only shows the default role mapping because I was exploring the UI, i have no intention of editing it
We want to integrate an id-provider from a third party. We actually have quite a lot of different roles for users from that third party, and we're fine (even thankful) to let them decide for themselves who should have which roles, so that we don't have to manage it for them. So far, a role mapping similar to that used in the default mapping ({{#tojson}}groups{{/tojson}}) might be fine. However, we don't want to let the third party set any group. For example, superuser would be out of bounds. So we're just trying to "role-namespace" their realm somehow. It could be by a whitelist or by simply prefixing roles we get from them.
Edit: The workaround is to create an equal number of role mappings that we have roles for them, using the "standard" role mapping method. I have considered that, and we will do it as a fallback. I just thought it would be simpler to have a single role mapping that fulfilled this requirement instead of a lot of them.
I think that claim_patterns are the closest solution to getting "anything but with whitelist/prefix" right now, it's just impractical that any hypothetical changes would require a reboot.
I'll think about other ways to solve this, but I think you could probably get what want by making the rules reject mappings for groups that fall outside of your pattern.
This assumes you can tell your 3rd party IdP that "group" claims must being with a prefix that matches their organization. That is you force the prefixing to happen on the id provider side, not in the role mapping.
I don't know whether that's true for your case.
If it is, then you can do something that says:
For the given realm
Map the "group" names to "role" names
Unless there is a group that has an invalid pattern
If you're willing to write and maintain a Java plugin then this can also be done with a custom realm, but that feels like overkill for what you're asking for.
Also, assuming you're on a paid license (not a trial) then can you raise a support ticket and ask them to submit an enhancement request to have a better solution for this (which might be to officially support painless scripts for role mappings) ?
You can ask the support engineer to talk to me if they want more details about what to put in the enhancement request.
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.