elytron security: define role mapper (was: ldap security - role mapper)

[hyperman1]

Description
ldap security today requires that the application has identical names for ldap groups and application roles. But this is not realistic. most orgs have a naming convention for ldap objects, which will clash with java group names.

Implementation ideas
Elytron has the required possibilities, they need to be made accessible from quarkus. You have to decide if this is ldap-only or general. Code goes more or less like this:

Adapt the class:

     In io.quarkus.elytron.security.runtime.ElytronRecorder # configureDomainBuilder:

I assume a config more or less like this:

   quarkus.security.grouptorole.SOME_LDAP_GROUP_NAME=role1,role2

Add something like:

	Map<String, Set<String>> roleMap = new HashMap<>();
	for  each GROUP & ROLE from the config:
		roleMap.put(GROUP, new HashSet<>(Arrays.asList(ROLE.trim().split(" *, *"))));
	<the realm builder, just after the call to setRoleDecoder>
                     .setRoleMapper(MappedRoleMapper.builder().setRoleMap(roleMap).build());

[hartimcwildfly]

Of course the mappings from groups to roles should be adjustable at runtime. But the usage of the role mapper itself should be fixed at buildtime or at runtime?

[hartimcwildfly]

The role mapper is defined in the elytron security domain (as you already wrote). The role mapper would also apply to other security-realms. So please rename the issue to: elytron security: define role mapper

[hyperman1]

Concerning:
But the usage of the role mapper itself should be fixed at buildtime or at runtime?

For us it doesn't matter. Some conflicting concerns, feel free to choose whichever you like ;-)

• dev and prod security may be drastically different, managed by different people with access to different security systems. An Infosec team might decide on the fly to change the rules. Hence, all security settings (not only the role mapper) should be runtime properties. -> Runtime
• As this is part of the LDAP story, do the same as the other LDAP parts -> Buildtime
• You want your config on dev to match the one on prod as close as possible, hence force usage of the same code paths -> Buildtime