Integrate security infrastructures with JBossSX

JBossSX uses JAAS to integrate application servers and security infrastructures

1 2 3 4 5 Page 5
Page 5 of 5

The final security-related file is outside of


. The


file in the JBoss server configuration directory is the JAAS login configuration file. That file consists of named login configuration entries. Here's the version of


that we will use for the tutorial:

 example1 {
 // A properties file LoginModule that supports CallerPrincipal mapping required
 example2 {
 /* A JDBC-based LoginModule
 LoginModule options:
 dsJndiName: The name of the DataSource of the database containing the Principals, Roles tables
 principalsQuery: The prepared statement query equivalent to:
     "select Password from Principals where PrincipalID=?"
 rolesQuery: The prepared statement query equivalent to:
     "select Role, RoleGroup from Roles where PrincipalID=?"
 */ required
     principalsQuery="select Password from Principals where PrincipalID=?"
     rolesQuery="select Role, RoleGroup from Roles where PrincipalID=?"

In the example file above, there are two entries,




. The


entry contains a single login module whose class name is

, which is required for successful authentication. The login module is passed a single option named


with a value of


. The


option authenticates anonymous users as the identity


. The


typically provides an identity to unsecured Web content that calls EJBs that use the


method. Since this method cannot return a null value as per the EJB specification, the application server must provide a mechanism to map the nonexistent user onto an identity. JBoss pushes this responsibility onto the security domain login modules.

Test the tutorial1.ear deployment

The example's final step is to test that the security constraints do in fact work. If your browser runs on the same host as the JBoss server, launch your Web browser and open the Web application


file located at


. Figure 7 shows what the Webpage should look like. Each link is a test case, with the expected result shown as




based on the specified security. We'll walk through links 1 and 4 to verify both a passing and failing test.

Figure 7. The tutorial1.ear index.html page Click on thumbnail to view full-size image.

The first link corresponds to the call sequence illustrated in Figure 8. Each access or method invocation lists the role that the caller must possess for the access to be granted.

Figure 8. The tutorial1.ear index.html page Click on thumbnail to view full-size image.

Traverse Link 1 to invoke the


and enter


for the username and


as the password in the login dialog. Figure 9 shows the browser result.

Figure 9. The expected browser result Click on thumbnail to view full-size image.

The JBoss server console should display the following output:

 [Default] User 'nobody' authenticated.
 [Default] User 'java' authenticated.
 [Default] PublicSessionBean.ejbCreate() called
 [Default] PublicSessionBean.echo, arg=Hello
 [Default] PublicSessionBean.echo, callerPrincipal=caller_java
 [Default] PublicSessionBean.echo, isCallerInRole('EchoUser')=true
 [Default] PrivateSessionBean.ejbCreate() called
 [Default] PublicSessionBean.echo, created PrivateSession
 [Default] PrivateSessionBean.echo, arg=Hello
 [Default] PrivateSessionBean.echo, callerPrincipal=caller_java
 [Default] PrivateSessionBean.echo, isCallerInRole('InternalUser')=false

The first

User 'nobody' authenticated.

line results because Tomcat tried to determine whether the servlet request had a remote user associated with it. That caused a query to the security interceptor with a null username and password, because the browser was not asked to provide any login information. The null username and password is authenticated as the anonymous user


we configured in the server


file. The following

User 'java' authenticated.

line is the result of the


authorization login. Note that


method's check to see if the caller has the


role returns false. This seemingly incorrect result is in accord with our interpretation of the

EJB 2.0 PFD2 spec

, which states on page 439:

Note that isCallerInRole(String roleName) tests the principal that represents the caller of the enterprise bean, not the principal that corresponds to the run-as security identity for the bean, if any.

Now follow Link 4 to try to access the


bean's echo method from the


. That should fail, since only the


has been configured to run as the


role. You should see a 500 error and a root cause exception with the message:

 Insufficient method permissions, principal=java, method=create, requiredRoles=[InternalUser];

This message verifies that the


element, which required a


role, is enforced. I encourage you to try the additional test cases in the


example and investigate the second example,


, which was created and deployed during the examples build. The


example differs from


only in its choice of security domain name and thus login module configuration.


uses a Java Database Connectivity-based login module to demonstrate how to access security information from a database.

Secure your J2EE apps

Although the mapping of application security roles onto a application server deployment environment is currently a nonportable, application-server-specific task, this article has demonstrated how the standard JAAS security could be used to implement the J2EE declarative security model using a simple


-based usage pattern. Hopefully, future versions of J2EE will extend the portability of security closer to the deployment layer using similar techniques based on JAAS or equivalent standards-based APIs. This article has peered into the JBossSX security manager implementation of the J2EE declarative security model used by the JBoss EJB and Web containers. It focused on how the JAAS login modules configured for a security domain provide the security information via a


usage pattern. I also covered the steps required to create a custom login module for security infrastructures not supported by bundled JBossSX login modules. With this information, you can secure your enterprise applications either by configuring the login modules bundled with JBoss or by writing your own. :END_BODY

Scott Stark currently serves as the lead developer for the JBossSX security extension framework and one of the lead developers for the JBoss kernel and the JBoss release manager; he is also a partner in the JBoss Group. He has a Ph.D. in chemical engineering; that field was where he started working with parallel/distributed computing on machines like the BBN TC2000 and CM2. Scott has been doing distributed computing for more than 10 years, using a number of languages and paradigms. His Java experience includes more than four years of work in the technologies that make up the J2EE platform. :END_BIO

Learn more about this topic

1 2 3 4 5 Page 5
Page 5 of 5