Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Enterprise Edition >

Customized EJB security in JBoss

Separate your security policy from your business logic

By Luke Taylor, JavaWorld.com, 02/15/02

  • Print
  • Feedback
.

Security is a key factor in developing many enterprise applications. Indeed, if you handle sensitive data or offer restricted services, you need a clearly defined security policy for your application and a framework that enforces it; you cannot let individual programmers guarantee that their code is safe. Server platforms such as J2EE (Java 2 Platform, Enterprise Edition) normally include some infrastructure to provide declarative security for your application components, usually via a role-based access-control system. Such systems do effectively move application security issues away from the programmer.

However, in some situations a security policy may define application-specific business rules beyond the declarative security model's scope. For an EJB-based (Enterprise JavaBeans) application, usually your only alternative is to place security code directly in the EJB business methods -- undesirably mixing business and security logic. The open source, J2EE-compliant JBoss application server offers a convenient proxy-based architecture for factoring out such custom security code into separate, configurable objects. In this article, I outline pressing reasons why you should use custom security, why you should keep it out of your business code, and how you can employ JBoss security proxies to secure your applications.

Note: You can download the source code examples for this article from the Resources section below.

Authorization mechanisms in an EJB server

As any article or book on the subject will tell you, a key area of application security is user-activity authorization: how do you control access to the components and services that your application offers? Once the system authenticates a user (typically by logging in with a name and password), it must check his every subsequent action to ensure that he has the necessary permissions. Most systems control access using a role-based mechanism -- they define a number of roles for the application, assign each user a subset of these roles, and specify the permissions in terms of the roles.

With such a mechanism, you delegate to the infrastructure -- in our case, a J2EE server -- the responsibility for applying the controls. The J2EE specification defines how to set up an application's roles and how to apply access controls to its services. To apply this mechanism to EJBs, you specify which roles can call which methods on a particular interface. When an EJB method is invoked on a user's behalf, then, before the invocation takes place on the bean implementation, the container checks whether the user has one of the roles required to call the method. If he doesn't, it raises a security exception and the method isn't called.

This all takes place outside the application code. The application's XML configuration files specify the security permissions, while the application server's security infrastructure defines the usernames and their associated roles. Scott Stark's "Integrate Security Infrastructures with JBossSX" (JavaWorld, August 2001) explains how to set up a typical J2EE application's security with JBossSX, and introduces the JAAS (Java Authentication and Authorization Service) architecture that JBoss uses to implement its security services. (I'd also like to thank Scott for providing useful feedback on this current article.)

  • Print
  • Feedback

Resources