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

tutorial1.ear

. The

auth.conf

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

auth.conf

that we will use for the tutorial:

 example1 {
 // A properties file LoginModule that supports CallerPrincipal mapping
     org.jboss.security.auth.spi.UsersRolesLoginModule required
     unauthenticatedIdentity=nobody
     ;
 };
 
 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=?"
 */
     org.jboss.security.auth.spi.DatabaseServerLoginModule required
     dsJndiName="java:/DefaultDS"
     principalsQuery="select Password from Principals where PrincipalID=?"
     rolesQuery="select Role, RoleGroup from Roles where PrincipalID=?"
     unauthenticatedIdentity=nobody
     ;
 };

In the example file above, there are two entries,

example1

and

example2

. The

example1

entry contains a single login module whose class name is

org.jboss.security.auth.spi.UsersRolesLoginModule

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

unauthenticatedIdentity

with a value of

nobody

. The

unauthenticatedIdentity

option authenticates anonymous users as the identity

nobody

. The

unauthenticatedIdentity

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

EJBContext.getCallerPrincipal()

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

index.html

file located at

http://localhost:8080/jaas-example1/index.html

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

[PASS]

or

[FAIL]

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

SecureServlet

and enter

java

for the username and

echoman

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

nobody

we configured in the server

auth.conf

file. The following

User 'java' authenticated.

line is the result of the

HTTP BASIC

authorization login. Note that

PrivateSessionBean.echo()

method's check to see if the caller has the

InternalUser

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

PrivateSession

bean's echo method from the

SecureServlet

. That should fail, since only the

PublicSession

has been configured to run as the

InternalUser

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

method-permission

element, which required a

InternalUser

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

tutorial1.ear

example and investigate the second example,

tutorial2.ear

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

tutorial2.ear

example differs from

tutorial1.ear

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

tutorial2.ear

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

Subject

-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

Subject

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