OK, I have cracked this now that I finally got back to it. The relevant documentation was found at:
The details are as follows. Suppose you originally had the following configuration using DynamicLoginConfig:
<server> <mbean code="org.jboss.security.auth.login.DynamicLoginConfig" name="scLoginConfig:service=scLogin"> <attribute name="AuthConfig">META-INF/sc-login-config.xml</attribute> <depends optional-attribute-name="LoginConfigService"> jboss.security:service=XMLLoginConfig </depends> <depends optional-attribute-name="SecurityManagerService"> jboss.security:service=JaasSecurityManager </depends> </mbean> </server>
<policy> <application-policy name="sc"> <authentication> <login-module code="com.sc.security.SCLoginModule" flag="required"> <module-option name="scOption1">value1</module-option> <module-option name="scOption2">value2</module-option> </login-module> </authentication> </application-policy> </policy>
Remove these two files from your EAR. Add the following to your standalone.xml (or standalone-full.xml or domain.xml, etc.) in the <security-domains> subsystem:
<security-domain name="sc" cache-type="default"> <authentication> <login-module code="com.sc.security.SCLoginModule" flag="required"> <module-option name="scOption1" value="value1"/> <module-option name="scOption2" value="value2"/> </login-module> </authentication> </security-domain>
You can probably use the CLI for this if that is preferable for you. Just don't ask me what the command is.
Even though you are referencing a class packaged in your EAR from the application server configuration it is OK; it seems that JBoss does not try to do anything until the security domain is referenced. I was even able to run this configuration in my IDE which delays the EAR deployment until after JBoss starts.
Hey, if you solved it, you should mark it answered so that other people with the same question know where to find the answer.
Thanks Shadow Creeper, I hadn't thought of that