Role mapping and Custom Security realm

[gsu (Georg Summer)]

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?

[Albert_Zaharovits]

Hello @gsu

As I understand it the role mapping API allows me to create mappings that (currently?) only the LDAP and AD authentication realms use.

AD, LDAP, PKI and soon SAML use the RoleMappingStore.

If I want to implement my own custom authentication realm I have to do the role mapping during the authentication step correct?

Role mapping is an indirection that you do not need.
The 'authentication step' is responsible for building the User entity. The User entity contains the principalName, roleNames, metadata and some other misc fields. The custom realm should build this User entity to contain the roleNames. In this case the 'authentication step' is complete. See: https://github.com/elastic/shield-custom-realm-example/blob/201ab9bef6e45a3ae23f3c113f988555f47846e2/src/main/java/org/elasticsearch/example/realm/CustomRealm.java#L129

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.

Make sure you check the Custom Realm Example

[gsu (Georg Summer)]

@Albert_Zaharovits

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.

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

[Albert_Zaharovits]

I understand, this is unfortunate. The custom realm was not designed to cover for this use case.

It is on our roadmap to support this as an internal realm but it will not be in the next release (6.2).