]
Darran Lofthouse resolved WFCORE-1103.
--------------------------------------
Fix Version/s: 3.0.0.Alpha2
Resolution: Rejected
Rejecting for a couple of issues.
Firstly security realms are deprecated and being replaced with WildFly Elytron. Within
Elytron where we do make use of JAAS security domains this will be through capability
references which means dependencies will be checked during model validation.
Secondly the realm dependencies as well as depending on domains in the security subsystem
they can also depend on JAAS configurations in a jaas.conf file for processes such as in a
HostController to dependency detection is not a simple task. Even in a domain hosted app
server the cross resolution of dependencies is very complex.
Security realms does not validate JAAS references to security
domains
---------------------------------------------------------------------
Key: WFCORE-1103
URL:
https://issues.jboss.org/browse/WFCORE-1103
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Security
Environment: Development Mac
Test Linux (Debian)
Reporter: Nicky Mølholm
Labels: jaas, logging, security, trace
Fix For: 3.0.0.Alpha2
*Problem*
In the server configuration file (standalone.xml) it is possible to define a security
realm that points to a security domain that does not exist - and there is no error
reporting of this at all. There is no trace information of this at all, either.
*Example*
* Download a stock Wildfly 8.1.0.Final
* Replace standalone.xml with this gist:
https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw...
Run it and you will see now errors at all. Despite the fact that the _FlawedRealm_ points
to a bogus security domain called _ThisDomainDoesntExistAtAll_ . I have captured my
logoutput too. Find it here:
https://gist.githubusercontent.com/nickymoelholm/4908092afdcd519361df/raw...
*What is wrong with this behavior?*
The bootstrapping process must validate that the configuration is valid indeed. It really
doesn't - not semantically that is. Only XSD compliance / XML syntax wise. And if, for
some weird reason, that silence is "security" - then at least let us know of the
errors on loglevel = TRACE.
*Why is this issue created?*
The silent behavior makes security configuration in Wildfly an _extremely expensive
operation_ in terms of time spent by the average Java EE developer / administrator. I have
created this issue because I want wildfly to help developers/administrators become better
at spotting our errors - because, in the end, that is a tangible productivity booster.