Java Reference
In-Depth Information
</login-module>
<login-module
code="RealmUsersRoles" flag="required">
<module-option
name="usersProperties"
value="${jboss.server.config.dir}/
application-users.properties"/>
<module-option
name="rolesProperties"
value="${jboss.server.config.dir}/
application-roles.properties"/>
<module-option name="realm"
value="ApplicationRealm"/>
<module-option
name="password-stacking" value="useFirstPass"/>
</login-module>
</authentication>
</security-domain>
. . . .
</security-domains>
</subsystem>
As you can see, the configuration is pretty short as it relies largely on default values,
especially for high-level structures like the security management area. By defining
your own security management options, you could for example, override the default
authentication/authorization managers with your implementations. Since it is likely
that you will not need to override these interfaces, we will rather concentrate on the
security-domain element, which is the core aspect of JBoss security.
A security domain can be thought of as a Customs Office for foreigners. Before the
request crosses JBoss AS borders, the security domain performs all the required au-
thorization and authentication checks and eventually notifies if he/she can proceed
or not.
Security domains are generally configured at server startup and subsequently bound
into the JNDI tree under the key java:/jaas/ . Within the security domain, you can
configure login authentication modules so that you can easily change your authen-
tication provider by simply changing its login-module .
Search WWH ::




Custom Search