Defining a Security Domain


The action of authenticating the user (verifying the user's password) and authorizing the user (checking whether the user has permissions to perform a given action) comes from something called a security domain. The ToDo application supplies user information in the users.properties and roles.properties files, but this works only because JBoss provides a default security domain that knows to look for those files. In this section, we'll override the default security domain and provide an explicit security configuration that can be customized later to meet the application's security needs.

How do I do that?

The conf/login-config.xml file is the central configuration point for security in JBoss. It provides the policies that define each security domain. Take a look through the file. You will see a collection of application-policy elements that declare the security domains in JBoss. Here is an example found near the end of the file:


Note: It's always helpful to read through the configuration files. Most configuration files in JBoss have lots of comments explaining the configuration options.
     <!--         The default login configuration used by any security domain that         does not have an application-policy entry with a matching name     -->     <application-policy name="other">         <authentication>             <login-module                code="org.jboss.security.auth.spi.UsersRolesLoginModule"                flag="required" />         </authentication>     </application-policy> 

This defines a security domain named other. It defines an authentication system that uses UsersRolesLoginModule, which reads user and role information from the simple properties files we have been using. The other security domain is the default security domain for the system. When JBoss doesn't find a security domain configured for the application, it uses this one.

If you want to change the authentication policy, you can make the change to the other security domain. However, this will change the default policy for the entire server, which likely is not the best strategy. A better strategy is to declare a new security domain. To do that, you need to create a new policy based on the original policy. Add the following policy to the login-config.xml file:


Note: Security domains are created on demand. Putting an entry in login config.xml doesn't have any effect until an application tries to use it.
     <application-policy name="todo">         <authentication>             <login-module                code="org.jboss.security.auth.spi.UsersRolesLoginModule"                flag="required" />         </authentication>     </application-policy> 

This declares a new security domain named todo. You'll need to restart the server for JBoss to see the changes to the file and recognize the new domain.

What happens when a security domain falls in the forest but no applications are around to hear it? That's the state the application is in. JBoss doesn't know that the ToDo application needs the todo security domain. Unless you specify otherwise, JBoss will continue to use the other domain.


Note: You can use the same security domain element in other JBoss deployment descriptors, such as jboss.xml.

To set the security domain, we need to introduce another JBoss-specific deployment descriptor, jboss-web.xml. jboss-web.xml sits next to the standard web.xml file in the WEB-INF directory of the WAR file and provides additional deployment information.

To link to a specific security domain, you need to set the security-domain element to the JNDI name of the security domain to link to. Security domains are bound under java:/jaas in JNDI, so the todo domain would be java:/jaas/todo, as shown here:

     <!DOCTYPE jboss-web PUBLIC               "-//JBoss//DTD Web Application 2.4//EN"               "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">     <jboss-web>         <security-domain>java:/jaas/todo</security-domain>     </jboss-web> 

Using the -Doptional.dd=security flag when you invoke the build script includes the descriptor in the jboss-web.xml file in todo.war:

     [todo]$ ant -Doptional.dd=security 

What just happened?

You created a new security domain named todo, backed by UsersRolesLoginModule, which replicates the functionality of the default security domain. Although this module is simple to set up, it is not very flexible to deploy. However, now that you have explicitly created the security domain and linked it to the application, you can swap out the login modules with any other implementation you desire, a process that is completely transparent to the application.



JBoss. A Developer's Notebook
JBoss: A Developers Notebook
ISBN: 0596100078
EAN: 2147483647
Year: 2003
Pages: 106

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net