The Geronimo renegade: Security and Apache Geronimo's future

An interview with David Jencks

A full-service application server like Apache Geronimo needs to have a full-service security implementation, and that means more than just supporting SSL connections. It means securing the internal requests made within an application. In this installment, David Jencks talks to the renegade about the current and future view of Geronimo's security implementation.


Nicholas Chase (, Freelance Writer

Nicholas Chase has been involved in Web-site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. He has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, an Oracle instructor, and the chief technology officer of an interactive communications company. He is the author of several books, including XML Primer Plus (Sams).

23 January 2007

One of the great things about open source software is, of course, the fact that anyone can participate, so the pool of resources is limited not by an annual hiring budget, but by interest in the project. That means you can have any number of developers, but it also means that one person may be involved in several areas if he or she finds them interesting.

Take David Jencks, for instance. I set out to talk to him about Apache Geronimo security, but quickly realized he was even busier than I had suspected. "Right now I am working on finishing JPA support with container-managed persistence," he told me when I sat down to talk to him just before Thanksgiving. "We have the Daytrader sample application working in Geronimo using OpenJPA. I'm quite excited by this; JPA looks like it will be a much better persistence solution than entity beans or even JDO1 (I haven't had a chance to work with JDO2 yet). I'm also working on integrating [Apache] CXF for the JEE5 JAX-WS support, and hope to get to Axis2 integration soon. I'm also trying to figure out how to refactor the deployment system to make it more extensible and simpler. And I'm hoping to find the time to actually demonstrate pluggable JACC. And if I get any free time I hope to get back to the Jetspeed 2 integration I started last year."

Now that's a busy schedule!

Doing things better

It's quite a list, but perhaps not surprising when you consider how David Jencks came to be part of the Apache Geronimo project in the first place. He was part of the group that worked on the original Geronimo code drop, because he felt that there had to be a better way of doing things. "I'd worked on JBoss for several years and had become disillusioned with the project management and quality of the code. I saw Geronimo as an opportunity to start over and write a better server."

Doing things better is his mantra, it seems. "Most of the code in Geronimo has been written by people who have already written an earlier version of similar code, so they have more ideas about how to do it better. Also, in Geronimo we've worked more on improving existing code than we did when I was working on JBoss. Of course, I have no idea what has happened at JBoss since Geronimo started, so this may not reflect the current state of JBoss," he added.

Apache Geronimo security

But much of what David has been working on involves security in one way or another, so I thought he'd be the one to talk to about something that had been on my mind for some time. How can you create a truly secure application when it's open source and anybody can see how you're doing things if they want to find a way around it?

"I think all security professionals agree that security by obscurity is no security, and that the only secure solutions result from published methods with very extensive review, testing, attempts to hack, and so on. (Not to say I am a security professional, but that seems to be the consensus.) I don't think we have had extensive attempts to break our security. I'm just saying that in general, secrecy about how your security system works does not improve security, but rather usually the reverse."

So what does it take to secure an application like Geronimo?

"As a J2EE/JEE container, our first priority is to support the specs," he told me. "EE security has two parts: one is specified fairly completely by the spec, and another left up to the container/JACC provider implementer."

JACC specifies how an application server and a security provider can talk to each other to determine whether a particular request should be fulfilled. It's not so much about what requests are served to the browser as it is about what requests are served internally. Should this internal application have access to the user's bank balance? Should that one be able to update the work schedule table? These decisions are made based on security roles.

Security roles

"The spec completely specifies role to permission mappings for permissions related to EE artifacts," David explains. "Here, a role is basically an arbitrary name or string. However, the spec does not specify how to determine if a user is in a particular role. That is basically the function of a JACC provider.

"Examples of roles might be administrator, user, hruser, and so on," he continues. "They're just names for some category of actions that is meaningful for the application or environment."

I wondered whether this was handled by the server or the application, or both. "Well, the idea behind EE declarative security is that the server handles the permissions without the application needing to check stuff explicitly. So you can declare for a Web app that one role can access pages in the /secure/admin realm, whereas another role can access pages in /notsosecure/workingstuff. Your Web app doesn't need any code to check who can do what, because the container handles that for you.

"Starting at the beginning of a request, the request will get some security information attached to it in the form of a subject created by a login configuration containing several JAAS login modules. This subject can have basically any kind of information in it in the form of principals and/or credentials. The job of the JACC provider is to take the information in the subject, possibly combine it with information from the request, and decide whether the request has permissions to do stuff."

Complications do arise, however, due to the fact that the JACC specification doesn't talk very much about how to map users to roles. "Each JACC implementation incorporates some idea of how to map users to roles. How to do it is not specified by the specs, and there are a lot of possibilities."

Apache Geronimo's implementation

"In Geronimo, we ask you to set up login modules in a security realm: this will result in users being represented by subjects that contain various principals. We assume the principals are basically name-class pairs and let you set up an arbitrary mapping between principals and roles. So, as a simple example, your login module might add principals of class MyRolePrincipal with names admin and/or user to the subject, depending on who you are. If the application then declares the roles SUPERUSER and PEON, you can map the admin to SUPERUSER and user to PEON," he said with a smile.

"Basically, we have a fairly straightforward JACC provider that lets you map arbitrary (simple) principals to arbitrary roles, but it doesn't use any information in the request. This is fairly well adapted to situations in which you have an existing security system that specifies some kind of role in some way, and there is a straightforward mapping from the security system idea of role to the J2EE idea of role. However there are a lot of other possibilities."

Future plans

I asked him what else Geronimo could be doing.

"I see three main areas to develop," he told me. "Integrating with other security systems, taking advantage of more JACC features, and improving what we have."

Integrating with other security systems

We spoke first about integrating with other security systems. "Our JACC provider implementation is about as flexible as we can make it on its own," David explained, "but it may be too general to administer conveniently. On the other hand, there are several security systems that provide good, powerful administration, from user registration down to managing permissions, and that could be adapted to be JACC providers. Two of these are the TripleSec project, which is about to become part of Apache Directory, and the Jetspeed 2 security administration system. These both provide flexible user and permission administration that I think can easily be adapted to be a JACC provider. They differ from our system in that they explicitly include all aspects of user administration, including LoginModules; the current Geronimo system is based on the idea of interfacing with existing user administration that already supplies appropriate login modules.

"While these possible integrations will not necessarily provide the flexibility of integrating with existing authentication systems (although TripleSec may integrate with existing corporate LDAP systems), they will provide powerful all-in-one security solutions that let you administer pretty much everything related to authentication and authorization in one place. There are also existing JACC implementations, such as one from IBM® Tivoli® software, that we would like to demonstrate working with Geronimo. Another feature these systems provide that is not in the current Geronimo implementation (and is not clearly covered by the spec) is the ability to change a user's permissions on the fly and generally administer the system while it is running."

Taking advantage of more JACC features

There are also other areas in which Geronimo's JACC implementation could use a little more attention. "One of the traditional limitations of J2EE security is that it has not had any way to express constraints, such as 'plain users can only transfer $50, super users can transfer $2000, and the boss can transfer as much as they want.' My understanding is that when such constraints appear, developers typically abandon J2EE security and start writing code for themselves. There have been several attempts to deal with this kind of constraint. JBoss used to have a concept of SecurityProxy for EJBs, where you could provide an implementation of the EJB business interface that could execute these security checks in code. My first contribution to JBoss was a rules engine integration that lets you evaluate rules on EJB method calls, and in particular you could fairly easily express constraints such as these on EJB method arguments and return values. JACC provides uniform access to request parameters so a JACC provider can use parameters (but not results) in the permission decision process. I think it would be pretty interesting to see a JACC implementation that provided an easy-to-use language for expressing such constraints. One possibility is XACML (eXtensible Access Control Markup Language), which appears to provide this and more."

Lessons learned

David Jencks seems to have better tattooed on his forehead. Certainly he's always thinking about ways to improve Geronimo. "Well, we learned quite a bit implementing CORBA CSIV2 and from talking to some CORBA and XACML experts, and that has led us to re-evaluate some of the non-CORBA authentication model. With authentication, the simplest situation is where you have a dumb client, such as a Web browser, and all it does is forward the user [and] password to the actual server; this is basically the same situation as running a program locally. Here, the server just checks to see if it knows about the user [and] password, and it's done. However, as soon as you get into more complicated situations in which the client isn't quite so dumb or is another server, you need a more sophisticated approach.

"Our original approach was to try to provide a way to run some login modules on the client and some on the server and combine the results on the server. For instance, you might need to run a Kerberos login module on the client, meaning the Kerberos system has actually authenticated the user. Our current implementation is awkward and difficult to understand. We think that we can provide a much cleaner, more powerful solution, similar to the CSIV2 model based on the idea of security assertions. Very roughly, the idea is that the user will log in to the client, and then the client will make various security assertions to the server. Basically these boil down to the client saying, 'Joe logged in, and you should trust me because of my credentials.' We think that we can make the authentication system simpler, easier to understand, and much more powerful."

Which begs the obvious question: Why isn't this implemented yet?

"We're long on ideas and short on manpower," David said, his enthusiasm showing through. "I think both the security assertion-based authentication and XACML or other rule-based authorization systems are fascinating and would love to work on them, but in the past year I've only managed to spend a few days on security making JACC pluggable. Alan Cabrera, who wrote the original version of almost all our security, has also been thoroughly occupied on other projects. Our XACML expert, Simon Godik, has pointed out several other improvements that we could make, short of a complete rewrite, but no one has had time to put them into practice. This year I'm hoping we can leverage some other communities, such as Apache Directory with TripleSec, to get some exciting features in without having to do all the work ourselves. One promising sign is that one of our new committers, Vamsavardhana Reddy, has been making a lot of progress on improving administration of some security features, such as the keystore. If we can attract more new developers for some of this, that would be even better!"


Geronimo may have been written from the ground up, but it certainly has a mature outlook on security. In addition to the security requirements in the J2EE specification, David Jencks and the rest of the Geronimo team have been looking hard at new ideas that can revolutionize how enterprise application servers work.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Open source on developerWorks

Zone=Open source, Java technology, WebSphere
ArticleTitle=The Geronimo renegade: Security and Apache Geronimo's future