Bug 1392436

Summary:	[GSS](6.4.z) security subsystem, audit provider-module lacks "module" attribute
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Tom Fonteyne <tfonteyn>
Component:	Security	Assignee:	Peter Palaga <ppalaga>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Josef Cacek <jcacek>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.4.11	CC:	anmiller, bdawidow, bmaxwell, darran.lofthouse, heiner.tittelbach, hokuda, ihradek, jochen.riedlinger, leiyu, msochure, pjurak, ppalaga, pskopek
Target Milestone:	CR1
Target Release:	EAP 6.4.14
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-23 08:22:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1401452

Description Tom Fonteyne 2016-11-07 13:56:23 UTC

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.

Comment 1 Jochen Riedlinger 2016-11-08 12:12:01 UTC

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.

Comment 2 Jochen Riedlinger 2016-11-08 12:30:44 UTC

please check, if the same bug is also in EAP 7. I think it's also in the new version

Comment 4 Peter Palaga 2016-12-23 13:50:14 UTC

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.

Comment 6 Peter Palaga 2017-01-03 16:05:39 UTC

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.

Comment 7 Peter Palaga 2017-01-05 13:20:36 UTC

PR sent to upstream https://github.com/wildfly/wildfly/pull/9517

Comment 12 Ivo Hradek 2017-02-27 10:59:12 UTC

Verified with EAP 6.4.14.CP.CR1;

Comment 13 Petr Penicka 2017-03-23 08:22:05 UTC

Released with EAP 6.4.14 on March 14 (ZIPs) and March 22 (RPMs).

Comment 14 heiner.tittelbach 2017-04-20 07:53:00 UTC

The solution works fine in ApplicationRealm with EAP 6.4.14. A ManagementRealm using the same security domain still causes problems during management operations.

Comment 15 Peter Palaga 2017-04-20 08:01:06 UTC

(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?