Custom Realm Mapper evidence always null

176 views
Skip to first unread message

Martynas Selvenis

unread,
Jul 5, 2022, 5:57:18 PM7/5/22
to WildFly
I have implemented a custom realm mapper. When user is trying to authenticate application goes through the process to get a correct realm, however, I find that Evidence is always null.

I'm aware that there was an issue raised in regards of this and it seems that it has been resolved on versions 1.15.0.Final and 2.0.0.Alpha10 but changing to these versions I'm still always receiving evidence as null.

pom.xml
<dependency>
<groupId>org.wildfly.security</groupId>
<artifactId>wildfly-elytron</artifactId>
<version>1.15.0.Final</version>
</dependency>

standalone.xml
<subsystem xmlns="urn:wildfly:elytron:13.0" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
            <security-domains>
                <security-domain name="HH-Domain" default-realm="HH-OpenInterfaceRealm" permission-mapper="default-permission-mapper" realm-mapper="HH-RealmMapper" role-decoder="roles-attribute">
                    <realm name="HH-CachedRealm"/>
                    <realm name="HH-OpenInterfaceRealm"/>
                </security-domain>
            </security-domains>
            <security-realms>
                <custom-realm name="HH-OpenInterfaceRealm" module="local.hhlogin" class-name="local.hhlogin.HHOpenInterfaceRealm"/>
                <custom-modifiable-realm name="HH-Realm" module="local.hhlogin" class-name="local.hhlogin.HHRealm">
                    <configuration>
                        <property name="dataSourceJndiName" value="java:/HDataSource"/>
                    </configuration>
                </custom-modifiable-realm>
                <identity-realm name="local" identity="$local"/>
                <properties-realm name="ApplicationRealm">
                    <users-properties path="application-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ApplicationRealm"/>
                    <groups-properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
                </properties-realm>
                <properties-realm name="ManagementRealm">
                    <users-properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" digest-realm-name="ManagementRealm"/>
                    <groups-properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/>
                </properties-realm>
                <caching-realm name="HH-CachedRealm" realm="HH-Realm"/>
            </security-realms>
            <mappers>
                <custom-principal-transformer name="HH-OpenInterfacePrincipalTransformer" module="local.hhlogin" class-name="local.hhlogin.HHOpenInterfacePrincipalTransformer"/>
                <custom-realm-mapper name="HH-RealmMapper" module="local.hhlogin" class-name="local.hhlogin.HHRealmMapper"/>
                <simple-role-decoder name="groups-to-roles" attribute="groups"/>
                <simple-role-decoder name="roles-attribute" attribute="Roles"/>
            </mappers>

Custom Realm Mapper
import org.wildfly.security.auth.server.RealmMapper;
import org.wildfly.security.evidence.Evidence;

import java.security.Principal;

public class HHRealmMapper implements RealmMapper {
    @Override
    public String getRealmMapping(Principal principal, Evidence evidence) {
        if (principal.getName().startsWith("<open-interface-user>"))
            return "HH-OpenInterfaceRealm";
        return "HH-CachedRealm";
    }
}

Diana Krepinska

unread,
Jul 13, 2022, 7:05:39 AM7/13/22
to WildFly
Hello, what version of WildFly are you using? The bugfix for https://issues.redhat.com/browse/ELY-2090 was resolved for elytron 1.15.0.Final which was incorporated in WildFly 23
Message has been deleted

Martynas Selvenis

unread,
Jul 13, 2022, 8:47:26 AM7/13/22
to WildFly
We are using JBOSS 7.4 I have also raised an issue on RedHat: https://issues.redhat.com/browse/ELY-2361

Martynas Selvenis

unread,
Jul 13, 2022, 11:01:43 AM7/13/22
to WildFly
JBOSS EAP 7.4.5.GA to be exact
Reply all
Reply to author
Forward
0 new messages