[Wildfly 26.1.2] Using variable subsitution for role-mapper

[Stefan Luteijn]

Hi all,

We're in the middle of a process to migrate our wildfly application to kubernetes. We're using the standard wildfly runtime image quay.io/wildfly/wildfly-runtime-jdk11:latest. To configure the standalone.xml to the needs of our different environments, we're templating some of the vaues in the standalone.xml. This has mostly worked like a charm, but we seems to have hit a rock trying to configure a role-mapper.

We use a variable at the address /subsystem=elytron/mapped-role-mapper=MyRoleMapper:write-attribute(name=role-map,value={${LDAP_MAPPING_APPLICATIEBEH}=[applicatiebeh]})

This results in the standalone.xml in the following code:

 <mapped-role-mapper name="MyRoleMapper" keep-mapped="true" keep-non-mapped="true">

    <role-mapping from="${env.LDAP_MAPPING_APPLICATIEBEH}" to="applicatiebeh"/>

</mapped-role-mapper>

The environment variable however does not seem to be picked up by the wildfly server. As soon as I substitute the ${env.LDAP_MAPPING_APPLICATIEBEH} varuable for a hardcoded value it works like a charm again. Am I missing something? Any help would be greatly appreciated.

Regards,

Stefan Luteijn

[Cameron Rodriguez]

Hi Stefan,

By default, WildFly overrides reading from environment variables. You can follow these steps in the Admin Guide to override it: https://docs.wildfly.org/27/Admin_Guide.html#overridden-attribute-value

Best,

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/332151a6-c7d7-48aa-bbaa-c97dfacb4a5bn%40googlegroups.com.

--

Cameron Rodriguez (he/him)

Software Engineering Intern

WildFly Elytron

caro...@redhat.com

[Stefan Luteijn]

Hi Cameron,

Thanks for your fast response. I think the option you're referring to is a different approach to provisioning wildfly configuration through variables. From what I can tell the WILDFLY_OVERRIDING_ENV_VARS=1 setting is used when directly overwriting wildfly configuration through an environment variable.

In my case I'm trying to use variable subsitution in the standalone.xml itself, which works for most cases but somehow not for role-mappings. My use case is described here: https://docs.wildfly.org/27/Admin_Guide.html#Expression_Resolution

When I try to resolve the expression through the wildfly cli, it does return the correct value:

[standalone@localhost:9990 /] :resolve-expression(expression=${env.LDAP_MAPPING_APPLICATIEBEH})
{
    "outcome" => "success",
    "result" => "APLBEHDEV"
}

Is it possible that I need to enable variable substitution / expression resolution specifically for role mappings? Or is it an unsupported use case that I'm attempting here?

Regards,

Stefan

Op dinsdag 14 februari 2023 om 17:48:29 UTC+1 schreef Cameron Rodriguez:

[Cameron Rodriguez]

Hi Stefan,

Sorry, you're right, I was checking the wrong section. I took a look at the code for the mapped-rore-mapper, and I believe it might be a bug. I'll get back to you once I've had more time to investigate.

Best,

To view this discussion on the web visit https://groups.google.com/d/msgid/wildfly/d9ce9ead-8487-482f-9ad6-b3f74db5ba83n%40googlegroups.com.

[Stefan Luteijn]

Hi Cameron,

Thanks again for your reply. If there's anything I can do from my side to verify or test, please let me know.

Regards,

Stefan

Op woensdag 15 februari 2023 om 20:30:56 UTC+1 schreef Cameron Rodriguez:

[Cameron Rodriguez]

Hey Stefan,

Thanks for your patience. I've confirmed it's a bug, and opened a report on the WildFly issue tracker to handle this: https://issues.redhat.com/browse/WFCORE-6244

Unfortunately it means that the mapped-role-mapper doesn't support expressions at the moment. In the meantime, the simplest solution would be to hardcode the mappings. Alternatively, you could create a custom-role-mapper. Briefly summarized:

1. Extend the existing mapped-role-mapper[1] into a new class. It still includes a method for loading mappings from the configuration, which does support expressions. Elytron has some documentation on how to create and deploy custom components[2].

2. Add the custom role mapper with the expressions. For example, if the class is `com.company.MappedRoleMapper`, with the module named `custom-mapped-role-mapper`:

/subsystem=elytron/custom-role-mapper=MyCustomRoleMapper:add(module=custom-mapped-role, class=com.company.MappedRoleMapper, configuration={key=${env.VAR1},key=${env.VAR2}})

The CLI command is slightly different since output mapping is a string instead of a list, and only values can be set with environment variables. Setting keys would require modifying MappedRoleMapper.initialize()

Best,

[1]: https://github.com/wildfly-security/wildfly-elytron/blob/b201a05f41e0e7b8bbedb05e275f6ee4a696a625/auth/server/base/src/main/java/org/wildfly/security/authz/MappedRoleMapper.java

[2]: https://docs.wildfly.org/27/WildFly_Elytron_Security.html#Custom_Components

[Stefan Luteijn]

Hi Cameron,

Thanks for your reply again. We'll try to implement one of the suggested workaround and meanwhile we hope that the solution to the bug will find its way to a wildfly release quickly :) Thanks so much for your help!

Regards,

Stefan

Op woensdag 22 februari 2023 om 00:31:16 UTC+1 schreef Cameron Rodriguez:

[Cameron Rodriguez]

Hey Stefan,

Just wanted to let you know that the fix for the mapped-role-mapper has been released with WildFly 28[1]. Thanks for bringing it to my attention!

Best,