Monday, December 29, 2008

Announcement: KeyCenter4NB 0.1

I'm very torn when it comes to choosing my Java development environment. I often swap between Eclipse and Netbeans. In fact, when I create a new project, I ensure that the project structure is compatible between the two, just in case the mood strikes me to swap back and forth. Eclipse is a fine IDE, however it is just a bit too rough around the edges in some respects for me. Netbeans, on the other hand, has some great features (UML, Matisse, a very powerful debugger and profiler, etc.) but I find it's Java editor very lacking and non-intuitive. The other problem I have with Netbeans is the lack of plugins. The Eclipse community has a far greater number of plugins available for it.

Recently, while working on some PKI-related code, I found myself wishing I had a plugin for viewing X.509 certificate details. After looking around, I really couldn't find anything suitable for my needs. I've never been really big on desktop GUI programming, mostly because I've never had the need to do it. All of my professional development has been on the J2EE side of things. However, I decided that if you want something done right you have to do it yourself, and decided I was going to write the plugin I was looking for.

After investigating both the Eclipse and Netbeans platforms, I decided to target Netbeans. I like the fact that Netbeans is pure Swing, and its GUI builder is second to none. I began playing around with module development, and was very pleasantly surprised with the experience. Yes, the Netbeans RCP has a very steep learning curve, and I've not even scratched the surface of what it is capable of. However, I've managed to create a very rough initial version of my plugin, KeyCenter4NB.

Initially, I was just looking for a plugin that would let me view the details of an X.509 certificate. However, the more I got into developing it, the more I wanted to eventually implement. As a result, the initial 0.1 version is just a certificate view. Future releases, though, will include tools for creating and manipulating Java keystores, creating PKCS #10 certificate requests, checking CRLs/OCSP, and other PKI-related functionality that a developer may need to take advantage of. A grand vision I'd like to implement (if I actually get enough time) would be a standalone application based on the Netbeans RCP that focuses on certificate and key management. However, that is a long way away.

In the meantime, check out the KeyCenter4NB project page and download version 0.1. Right now, you must download the .NBM packages and manually install them. I hope to have an update center for the project configured and running shortly. As I mentioned, it's very basic and I'm sure it's rough around the edges. But, I'll continue to update is as I learn more.

Monday, September 22, 2008

Syntax Highlighting in Blogger

Recently, I've gone through and added syntax highlighting to some of my previous posts. This was done for Java, XML, and SQL. There is a great set of CSS files and JavaScript to accomplish this called SyntaxHighlighter. The downside, however, is that Blogger does not make integrating these tools very easy. I tried several times, but always managed to screw something up. As a result, I was very happy to come across a Blogger Widget for SyntaxHighlighter. All you need to do is add this widget to your blogger layout. Remember to leave the title blank so that you don't see an empty section in your sidebar. Once you've added this widget, you can add syntax highlighting similar to what you see here. To highlight Java, for example, edit the HTML of your post and surround your Java code with :

<pre name="code" class="java">

That's all there is to it. A finished example would look like this, once highlighted:

public class MyClass {

private int myInt = -1;

public int getMyInt() {
return this.myInt;

public void setMyInt(int myInt) {
this.myInt = myInt;

Wednesday, July 30, 2008

Intro to JBoss Seam Security, Part 3 -- Authorization Rules with Drools

In previous articles, we have looked at how JBoss Seam handles security, particularly user authentication. Through the use of its Identity and Authenticator APIs, Seam provides an easy way to authenticate a prospective user without forcing a developer to implement hundreds of lines of code. In addition, Seam also provides CAPTCHA support, enabling an application to test for the presence of a human user, rather than a bot attempting to access an application. No doubt, Seam 2.1's forthcoming identity management API will make the process of creating and managing user accounts even easier. (Although, that is an article for another day)

While authentication is vital to application security, it is not the only aspect of security that must be accounted for. Authorization -- the process whereby it is determined what resources or actions a user may access -- takes authentication one step further, and cannot be overlooked. It is easy to come up with examples of where authorization should be determined within an application. A banking site would want to ensure that an authenticated user is, in fact, the owner of the bank account they are trying to access. A health insurance provider needs to check if an individual should be allowed to view recent claims that have been submitted. To accomplish this, some sort of authorization rules need to be established. Java EE already allows for programmtic authorization checks through the use of the HttpServletRequest.isUserInRole() method. Seam, however, takes authorization further and allows for integration within enterprise applications through the use of an authorization rules engine.

Seam uses the Drools business rules engine to allow complex authorization rules to exist outside of the Java code itself. Business rules engines have long been used to drive business operations or make decisions related to a specific business process (i.e. Approve a loan for an individual if they make more than $150,000 per year and have less than $25,000 in existing debt.) Now, these same types of rules can be applied to application security logic. Imagine a site like Facebook and how it approaches security. Facebook has very well-defined rules for how its information can be accessed. A profile is only visible to a member if the profile owner is friends with the member. Picture X can only be viewed by family members and friends, not coworkers. Member A can send a friend request to Member B provided that: 1) Member A != Member B, and 2) Member A is not already friends with Member B. It would be very easy to implement rules like this in Java code, either in the view or business layer. However, in our example application, we will separate these rules from our Java code and implement them using Drools.

Our simple example will be a social network site. Like any social network, ours will have some basic rules established to ensure the security of our site. The rules we will implement are:

  1. Administrators may do whatever they please
  2. A friend request may only be submitted if the sender != recipient
  3. A profile is only visible by its owner and their friends

Our example will consist of two main objects:

public class Member implements Serializable {


public Set<Member>getFriends() {

public void setFriends(Set<Member> friends) {

public class MemberAction {


private Member authenticatedMember = null;

public void viewProfile(Member member) {

public void sendFriendRequest(Member recipient) {

public void deleteProfile(Member member) {

For the sake of time, we will not discuss basic dependency injection concepts. It should be obvious that MemberAction.authenticatedMember is related to the profile of a user who has successfully authenticated against the application. There are two primary ways we can perform an authorization check in the business layer using Seam: 1) Through annotations, or 2) Inline, using Java code. In addition, we can also perform security checks in the view layer to display or hide links or data based on the outcome of the check. We will discuss all of these methods for performing the checks as we move forward.

Before we are able to write and test our security rules, we must first enable them in our Seam configuration, and ensure our rules file is located in the right place. The components.xml file must have the following lines to tell Seam that we wish to use Drools for authorization:

<drools:rule-base name="securityRules">

As you can see, we have configured our security rules file to be located at /META-INF/security.drl. It is important that this file exists, otherwise our applications will not work as we expect. To tackle our first rule, "Administrators may do whatever they please", we need to establish a rule that allows administrators to be granted whatever permissions they request. Since this is a relatively simple rule, it will serve as a good starting point for our introduction into Drools syntax. Our rule will look like this:

package MySecurityRules;


rule AdminsCanDoAnything
c: PermissionCheck(name == "member")
Role(name == "admin")

Let's take a look at the syntax for this rule. On line 1, you will see a package declaration. This is not the same as Java packages. Drools packages are used to group Drools rules together. They are not used for anything else. On lines 2 and 3, you see two import statements. This lets Drools know that we will be referrencing the specified classes as part of our rule. It is imporant to include these lines, otherwise our rule will fail. Line 4 marks the beginning of the rule itself. Our rule is called "AdminsCanDoAnything". There is no specific naming requirement for your rule, other than the fact that it must be unique within the given package. Typically, the rule name is a description of what the rule actually accomplishes. The rule is divided into 2 sections, the "when" and the "then". The "when" section consists of one or more conditions that must be true for this rule to fire. If any of these conditions is not met, the rule will not fire. Once all conditions have been met, the rules engine moves on to the "then" section, and performs whatever commands are specified.

Lines 6 and 7 provide the authorization check itself. Line 6 is the first condition that must be met for this rule to fire. The line:

c: PermissionCheck(name == "member")

can be explained as, "there must exist a PermissionCheck object with a name property of "member" within the current working memory. This object will be called 'c' in this rule." If this condition is met, the engine moves on to line 7. Line 7 specifies that, "there must exist a Role with the name 'admin' within the current memory." By now you're probably wondering, "What is 'the current memory'?" Drools has its own context or working memory that it uses when evaluating a rule. It essentially acts as a session for the rules engine. Before an object can be considered within a rule, it must be added to the working memory. Whenever a permission check is performed via the hasPermission() method, a PermissionCheck object is created and inserted into the working memory. This object contains the name of the object the check corresponds to, and the action that is being attempted. In our example, the name of the object is "member". You'll notice that we have not specified an action in our check. This results in the rule corresponding to all possible actions pertaining to member. In addition, any Roles that a user belongs to will be inserted into the working memory prior to a rule check. This is how we determine the contents of our example security rule. It is also possible to insert an arbitrary object into the working memory by calling

((RuleBasedIdentity) RuleBasedIdentity.instance()).getSecurityContext().insert();

This will come in handy in our next article as we discuss Seam security rules futher. Now that we have defined our authorization rule, we can apply it and perform a permission check. For this example, we want to hide the link for the deleteProfile action from our view layer. Normally, however, we would also apply this permission check in the action itself to prevent users from circumventing our view-layer check. To perform a permission check on our link, we simply add the following to our JSF file:

<s:link value="Delete Profile" action="#{member.deleteProfile(...)}"
rendered="#{s:hasPermission('member', 'deleteProfile', null)}" />

Now, when our view is displayed, the permission check will be performed prior to rendering the link. Since our admin users have been granted all permissions, the link will be rendered. If we wrote an additional rule restricting access to the deleteProfile(), our admins would still be able to view the link, while other users that fail the permission check will not see the link.

In my next article, I will discuss how to implement our two remaining authorization rules, as well as the other ways of performing a permission check within your code.

Saturday, July 26, 2008

Building Seam Apps for Tomcat with JBoss Tools

One of the things I really like about the Seam framework is how much easier J2EE development is, particularly with respect to pulling the various components together. With Seam, it's very easy to build applications that utilize JSF, EJBs, and JPA. However, it's often preferable to develop more lightweight applications. While EJB3 has made enterprise development much more lightweight than in the past, there is still considerable overhead associated with it, particularly when you make use of a full-blown J2EE application server like JBoss. Sometimes, it's better to utilize a simpler approach and deploy your application using a Servlet Container like Tomcat.

The JBoss Tools project goes a long way towards making the actual development process with Seam much more user friendly. JBoss Tools provides a set of Eclipse plugins designed to work seamlessly (pun intended) with the framework. One of the drawbacks of JBoss Tools, however, is its lack of proper integration when creating a project you wish to deploy to Tomcat. In this post, I'll show you the changes you'll need to make to your Eclipse projects if you want to deploy your application to Tomcat.

To start, I'll assume that you have already downloaded Tomcat and defined a Server for it in Eclipse. It's very important to remember that you need Tomcat 6, in order to have support for the Servlet 2.5 specification. Once you've downloaded and setup Tomcat in Eclipse, you're ready to create your JBoss Tools project.

Create your JBoss Tools Seam project, just as you would a regular Seam project, by clicking File->New->Seam Web Project. This will start the new project wizard. However, when selecting your Target Runtime, select your Apache Tomcat 6.0 runtime, as shown in the image below.

Click next, and select whatever project facets you may need. Click next through the wizard and fill in the appropriate fields according to your project needs, until you get to the following screen.

In this screen, be sure to select a WAR file for your deployment, as Tomcat only understands WARs, not EARs. Click Finish, and your project will be created. Now, we need to make a couple of changes to support Tomcat in our project. We'll start by ensuring that the necessary Seam libraries are a part of your project. The following libraries need to be placed in your WEB-INF/lib directory:

  • antlr.jar
  • asm.jar
  • cglib.jar
  • commons-beanutils.jar
  • common-collections.jar
  • commons-digester.jar
  • commons-lang.jar
  • commons-logging.jar
  • dom4j.jar
  • hibernate-annotations.jar
  • hibernate-commons-annotations.jar
  • hibernate-entitymanager.jar
  • hibernate.jar
  • hibernate-validator.jar
  • javassist.jar
  • jboss-archive-browsing.jar
  • jboss-el.jar
  • jboss-seam-debug.jar
  • jboss-seam.jar
  • jboss-seam-ui.jar
  • jsf-api.jar
  • jsf-facelets.jar
  • jsf-impl.jar
  • jstl.jar
  • jta.jar
  • persistence-api.jar
  • richfaces-api.jar
  • richfaces-impl.jar
  • richfaces-ui.jar
Once these libraries are in place, your project will build successfully and deploy correctly to Tomcat. Now, we need to look at the Resource configuration to support JPA for object persistence. First, we need to create a context.xml file and place it your META-INF directory. This is the file that Tomcat uses when deploying your project to setup the context root, as well as any resources that need to be made available to your project. With a JBoss deployment, your database settings are placed in a separate file, like MyProject-ds.xml. With Tomcat, we will place all of these settings in our context.xml file. Once completed, it will look like this:

<?xml version="1.0" encoding="UTF-8"?>
<Context crossContext="true" debug="5" docBase="myproject" path="/myproject" reloadable="true">
<Resource auth="Container" driverClassName="com.mysql.jdbc.Driver" maxActive="20"
maxIdle="10" maxWait="-1" name="jdbc/myproject type="javax.sql.DataSource"
username="myuser" password="mypassword" />

We also need to modify the persistence.xml file used by JPA. The JNDI name that Tomcat utilizes differs from what JBoss uses. Instead of "java:/", our datasource needs to start with "java:comp/env". Our persistence.xml file will now look like this:

<persistence xmlns="" xsi="" schemalocation="" version="1.0">
<persistence-unit name="MyProject" type="RESOURCE_LOCAL">
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQL5InnoDBDialect" />
<property name="" value="update" />
<property name="hibernate.show_sql" value="true" />
<property name="hibernate.format_sql" value="true" />
<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup" />

Lastly, we need to modify some settings in our components.xml file. First, remove the jndi-pattern="@jndiPattern@" attribute from the following line:

<core:init debug="true" pattern="@jndiPattern@">

At this point, we should be ready to deploy our applicaion and test it out. Take a good look at the log files in case your application doesn't deploy correctly. However, if you followed the above steps, everything should work as expected.

Friday, March 28, 2008

Dogtag -- Open Source PKI from Red Hat

Earlier this month, Red Hat announced they were open-sourcing the PKI platform they purchased from Netscape in 2004. The resulting project, Dogtag, contains an open-source version of the code used to power Red Hat Certificate System, previously known as Netscape Certificate Management Server. While Red Hat is most known for their Linux distribution (and, more recently, their JBoss middleware products), RHCS is the basis for the world's largest PKI, developed and maintained by the U.S. Department of Defense. This PKI is responsible for nearly 10 million certificates, including those issued on the DoD's Common Access Card (CAC).

So what does this mean for the open-source community at-large? Plenty. Up until now, there has been no enterprise-class, open-source PKI solution (despite the efforts of your's truly and the Odyssi PKI project). While the community often argues that PKI is too bloated and unnecessary when compared with PGP or other lightweight products, it serves as the backbone for security in many large-scale enterprises. Being able to deploy an open-source PKI is yet one more component that Red Hat is able to provide in the application stack. This, combined with their support of the FreeIPA project for providing identity, audit, and policy management, means that Red Hat is becoming an even more formidable player in the enterprise space.

I have worked extensively with Netscape CMS, the basis for RHCS. The features, scalability, and security it provides are top-notch. In fact, many of the features in CMS served as the inspiration for things I had planned for Odyssi PKI. Will I continue development of Odyssi PKI now that Dogtag is available? Maybe, maybe not. Life seems to be getting in the way of any development projects for right now. However, in the future I may have time to continue with Odyssi PKI, or even contribute to Dogtag. We'll just have to wait and see.

Thursday, February 7, 2008

Intro to JBoss Seam Security, Part 2 - Advanced Authentication

In my last post, I gave a brief introduction into how JBoss Seam handles user authentication for web applications. By simply creating an authenticator class, it is possible to handle login/logout events for your application. Seam's ability to inject an identity object means that a user's identity can be accessed wherever necessary.

This method works great for simple use cases. But, what if you need more advanced functionality? The ability to enable/disable an account; the ability to manage account creation; the ability to add or remove a role programmatically. Suddenly, there is a lot more code necessary for our application to function appropriately. Thankfully, Seam has an answer to this problem.

The IdentityStore interface defines the methods for creating accounts, changing passwords, and many other account lifecycle functions. By implementing this interface and its corresponding methods, it is possible to hook into existing authentication stores, such as LDAP, and still be able to manage the account via an administrative interface.

Seam also provides a sample implementation that can be used to store accounts and roles in a database, JpaIdentityStore. The JpaIdentityStore class makes use of the Java Persistence API for storing account and role objects in a SQL database. In order to make use of the IdentityStore implementation, we need to tell Seam that we will be using it. In addition, we need to define the class that will be used as our account model object. To do this, we need to add the following line to our components.xml file:

<identity-management:jpa-identity-store name="identityStore" account-class="com.myapp.UserAccountModel"/>

As you can see, we have defined our account model as com.myapp.UserAccountModel. All that is needed is to implement this object and add the appropriate annotations so that JpaIdentityStore is able to make use of our data model.

The IdentityStore interface is simple enough that it can be implemented in a matter of hours. Whether you want to use JNDI, Kerberos, or a custom authentication method, it is simple to get up and running quickly. For more information on the IdentityStore and identity management APIs provided by Seam, take a look at this section in the documentation.

Next time, we'll take a further look at JpaIdentityStore and how to setup and configure it to work with your existing SQL table schema.

Wednesday, January 23, 2008

Intro to JBoss Seam Security, Part 1 - Authentication

Recently, I mentioned how I had just started working with the JBoss Seam application framework. The more I have worked with it, the more impressed I have become at how it makes things that are typically difficult using standard Java EE much simpler and more streamlined. One of the areas in which Seam really shines is security. While Java EE defines JAAS for use in securing applications, it is left up to the developer to ingrain this security down to each facet of the application. With Seam, it is easy to define security constraints at all levels of an application, simply through using annotations. In addition, the complexity of authenticating users with JAAS is reduced through Seam's authenticator mechanism. This article will give an introduction to Seam authentication, and show how to write your own custom authenticator.

Seam's authenticator construct hides the complexity of managing a JAAS configuration, and allows you to implement authentication how you see fit. Perhaps your organization relies on a simple username/password combination for authenticating user accounts in LDAP. Maybe you use a SecureID token, and the accounts are stored in a SQL database. By writing your own authenticator class, or making use of publicly available ones, you can control the way authentication is done in your organization.

To get started with your own authenticator, you must first declare it in the components.xml file. This file manages much of the configuration for Seam. To add your authenticator, you simply define the class and method that will be used for authentication. For example:

<components xmlns=""

<security:identity method="#{authenticator.authenticate}">


You'll notice the #{} syntax used here. This is JBoss' expression language pointing to a class with the instance name of authenticator, where the authenticate method will be used to login a user. Now that we have declared an authenticator to Seam, we're ready to implement it. Our example will be quite simple. If the user enters a username of admin, with a password of password, they will be authenticated successfully. In addition, we will assign them to the role of admin, so that they can perform some sort of administrative function within our application. The implementation of our authenticator would look like this:

public class Authenticator {

private static final String valid_user = "admin";
private static final String valid_password = "password";

public boolean authenticate() {
String username = Identity.instance().getUsername();
String password = Identity.instance().getPassword();

if((username.equals(valid_user)) && (password.equals(valid_password))) {
return true;

return false;

Our example is rather trivial. However, it gives a slight glimpse into how Seam authentication works. The first thing that you should notice is the @Name annotation. This annotation prompts Seam to create a bean with the name specified in the annotation. In this case, the name is authenticator, which is how we arrive at the value specified in our components.xml file. Our authenticate method will return true if authentication was successful, and false otherwise.

So how does the authenticate method get the username and password? This is done via the Identity class. The standard Identity class that comes with Seam is quite extensive, but basically provides support for a username/password combination. It is possible to subclass Identity, however, to support whatever authentication mechanisms you may need. You could implement code to support getting a SecureID token value from a user, or a SPNEGO ticket. All that is needed to make use of the Identity subclass is to add the following annotations to your implementation:

@Install(precedence = APPLICATION)
public class MyCustomIdentity extends Identity
{ ... }

Your custom Identity subclass is now ready for use.

Now that we have our authentication classes in place, we are ready to create our login form. This is trivial to create using Seam, particularly because of Seam's use of the JBoss expression language in forms. Our login form fragment would look like the following:

<h:outputlabel for="name" value="Username">
<h:inputtext id="name" value="#{identity.username}">

<h:outputlabel for="password" value="Password">
<h:inputsecret id="password" value="#{identity.password}">

<h:commandbutton value="Login" action="#{identity.login}">

That's all there is to it. You are now ready to authenticate users via your own custom login form and authenticator. While this is an introduction to the simplified form of authentication in Seam, it should give you a good foundation to learn and explore on your own.

Next time, we will look at how authentication is used throughout an application, not just at the entry point.

Thursday, January 17, 2008

JBoss Seam - J2EE Development Framework

I know I have repeatedly said that an update to OdyssiPKI is forthcoming. But, I keep getting sidetracked by interesting technologies that I just have to check out. With this update of OdyssiPKI, I decided to make it a bit more robust, and to spend more time focusing on the overall design and engineering of the application. With that came the decision to make use of EJB's, particularly EJB3. In addition, I decided to try moving away from Struts and look into Java Server Faces (JSF) for the main user interface. Of course, all these changes mean that there is a lot more that I need to get familiar with before the next release is ready.

The primary motivation for such a radical change in the project design was to make OdyssiPKI a more robust application. Currently, the user interface is very lacking. It is a simple Struts interface, and is generally not very user-friendly. In addition, the backend components of the application are very simple. Transactions, scalability, and enhanced security were not a primary focus of the first release. The combination of EJB3 and JSF makes correcting these issues much easier. The security provided by EJB3 annotations means more fine-grained control. In addition, by utilizing EJBs for the business logic, the scalability of the application is enhanced. Further, anyone who has looked at Woodstock, RichFaces, or MyFaces, and it's spinoff projects has seen what a rich interface JSF is able to provide.

The downside to all of this change? Overhead. EJB3 and JSF add a lot of overhead to the application structure. Annotations, XML files, deployment descriptors, etc. All of this creates a pretty steep learning curve, and means that development takes even longer. It is frustrating, as a developer, to have to spend so much time writing XML files when I'd rather be writing code. This is why I was very intrigued to discover JBoss Seam. Since I was already planning to develop and deploy using JBoss, it seemed like it might be worth investigating this new application framework.

JBoss Seam is an application framework designed specifically for JavaEE applications. It integrates extremely well with JSF and EJBs, as well as other Java technologies, such as Spring and Hibernate. Seam handles dependency injection as well as dependency "outjection" of various components, making it easy to assemble application services. The result? The overhead and time-to-market for JavaEE applications is drastically reduced. Seam is as close to Rapid Application Development (RAD) as I've ever seen when it comes to Java applications. And, the code generation tools included with the Seam distribution make project development even faster.

One of the most interesting tools included with Seam is seam-gen. The seam-gen utility has the ability to generate a complete project structure for Eclipse or NetBeans, simply by running Ant and answering a few questions about the overall structure of your application. Deployment descriptors, a basic interface and project files are automatically generating using the parameters you supply. In addition, you can even generate data models from an existing SQL database. All you need to do is supply the necessary connection parameters.

If you are looking for an application framework that allows you to develop robust applications very quickly, make sure you take a look at Seam. In addition, I highly recommend downloading JBoss Tools. JBoss Tools is a group of Eclipse plugins for working with JBoss, Seam, Hibernate, and other Java technologies. Getting started with Seam in Eclipse is as simple as creating a new "Seam Plugin" and following the wizard. All of the necessary files, projects, and basic classes are created for you automatically.

I'm still experimenting and getting familiar with Seam myself, but will sure to post a tutorial in the near future. In the meantime, here are a few good articles explaining Seam a bit further.