As I understand it the role mapping API allows me to create mappings that (currently?) only the LDAP and AD authentication realms use.
If I want to implement my own custom authentication realm I have to do the role mapping during the authentication step correct?
I do not want to replicate too much functionality, so I want to reuse whatever magic the LDAP and AD realms use (and through that the role mapping API). I found a NativeRoleMappingStore but where do I get that from when creating initializing my custom realm?
The RoleMapping service translates metadata to roleNames. This is because, in this case, the system doing authentication (LDAP/AD server) or issuing the certificates, can not possibly hold the notion of roles for each third party Service requiring authentication. Instead the 'authenticating party' releases a set of claims (eg groups) that are copied to the metadata field and subsequently translated to role names by the RoleMapping service.
I found a NativeRoleMappingStore but where do I get that from when creating initializing my custom realm?
Even if you fancy using RoleMapping in your setup with a Custom Realm, this is not currently possible.
Our custom realm is essentially a JWT custom realm and the idea was to only keep groups in the JWT object and let x-pack do the mapping (via the RoleMapping API). Essentially the same use-case you describe for the internal realms.
I can (and in this case have to) now query ES for the role mappings myself and apply them correctly.
Maybe it was just us, but as the documentation is currently, it strongly suggests that the RoleMapping is done independent of the Realm and not a specific concern each realm handles itself (especially the custom realm).
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.