When adding a provider module for auditing: [standalone.redhat.com:9999 /] /subsystem=security/security-domain=LdapRealm/audit=classic/provider-module=test:add( => hit TAB code= module-options= There is no attribute "module" which would allow a customer to install a custom module. Workaround: custom jar file must be added to the "org.picketbox" module. However, this needs to be checked/redone each time a CP is installed making it a big overhead when a customer has many installations. Logging as a bug and not an RFE, as the presence of the "module" attribute was expected.
the "module" attribute is not only expected, it is even defined in the "<xs:complexType name="providerModuleType">" of the jboss-as-security_1_2.xsd schema.
please check, if the same bug is also in EAP 7. I think it's also in the new version
A side note: I think there is an (untested!) hope that the fix (underway) for Bug#1280512 "A security-domain can only load login-modules from a single JBoss module" will partly fix also the present issue. I say partly, because it will help only if the custom audit provider implementation is in one of the JBoss modules that provide LoginModules for the authentication - i.e. if the security domain looks like this <security-domain name="my-domain" > <authentication> <login-module code="org.myorg.security.MyCustomLoginModule" flag="requisite" module="org.myorg.security"> ..... </login-module> <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required"> ..... </login-module> </authentication> <audit> <provider-module code="org.myorg.security.MyCustomLogAuditProvider" /> </audit> </security-domain> AND MyCustomLogAuditProvider class is available in org.myorg.security JBoss Module, then the container should succeed in loading MyCustomLogAuditProvider from org.myorg.security in spite there is no module="org.myorg.security" in <provider-module ... > element.
I tested what I hoped for in Comment#4 and the result is that although the fix for Bug#1280512 is a substantial part of the solution for the present issue, it is not enough. A small change is still needed to fix the present issue. I prepared a fix for the upstream in this branch https://github.com/ppalaga/wildfly/commits/WFLY-7808 and I'll turn it into a PR once a blocking https://github.com/wildfly/wildfly/pull/9508 gets merged.
PR sent to upstream https://github.com/wildfly/wildfly/pull/9517
Verified with EAP 6.4.14.CP.CR1;
Released with EAP 6.4.14 on March 14 (ZIPs) and March 22 (RPMs).
The solution works fine in ApplicationRealm with EAP 6.4.14. A ManagementRealm using the same security domain still causes problems during management operations.
(In reply to heiner.tittelbach from comment #14) > The solution works fine in ApplicationRealm with EAP 6.4.14. A > ManagementRealm using the same security domain still causes problems during > management operations. Hi Heiner, thanks for the feedback. Could you please open a new support ticket?