Simon Brown's Blog

I have Servlets

In Got Servlets?, Greg is asking what we'd like to see in the next major revision of the Java Servlets specification. In no particular order, here are my initial thoughts.

• Programmatic access to the security realm : There are more and more sites out there that offer users a way to sign up for their services and this is fairly tricky to do with the standard, declarative J2EE security model. If you know that you're using a particular platform (e.g. Tomcat), then you can write some code that takes advantage of the underlying way in which the security credentials are stored, and edit them appropriately. But what about when you're targeting more than a single application server platform? What about when your team is developing on Tomcat and deploying to WebLogic? In this situation, being able to access an abstraction of the underlying realm implementation would be very useful. Self registration then becomes much easier - create a principal, assign some roles and write it back to the underlying realm in a platform independent way. Yes, you can do this with external security frameworks, but it would be nice to have this as a part of the standard.
• Programmatic access to the security constraints : Following on from the point above, programmatic access to the security constraints of the current web application would also be really useful. Self registration on it's own lets you build applications where the content presented to the user varies based upon who that user is. However, what you can't really do is change the security constraints of the web application on the fly. For example, imagine you're a blog hosting provider. You might want to let users self register for a public blog. On the other hand, you might want to let them register for a private blog, secured by the declarative security constraints in the web.xml file. Given the choice of using filters or security constraints in the web.xml file to permit or disallow access, I'd rather use the declarative approach because it's tried and tested code, reducing the risk that my site will be breached. This is one of the major benefits of using declarative security - the container does this work for you. Again, stopping people reinventing the wheel each time the security system doesn't work for them would be nice.
• Specification ambiguities : Inconsistency through ambiguity is a major headache for many developers, although I'd say that it's an even bigger headache for people wanting to build J2EE applications that really can run anywhere. Take Inconsistency between Servlet specification implementations as an example. Some containers provide you information about whether a user is logged in and some don't. Things like this really do need to be addressed. At the heart of this problem are ambiguities in the specification, but I'd say that the test cases around specification compliance need to be greatly improved. After all, what's the point of having a bunch of "J2EE compatible" application servers if they are inconsistent in how they implement the specs. Greatly reduces the benefit of the certification, don't you think?
• Regex URL patterns : The current wildcard scheme for specifying "url-pattern"s is far too limiting. Regex support would be nice, particularly now since newer versions of the J2EE spec mandate the use of versions of J2SE that contain regex support.

On a more general note, admittedly I've not used Java 5 annotations much, but I'm one of these people that is a little bit skeptical of them. They do have their uses, but I am a little concerned about them being overused, for example, to configure components through the code. Mike Spille has a great blog entry named Action Hippo Rangers! where he talks about the ping pong nature of software development. One of the examples he cites is the adoption of annotations versus XML configuration. The point is, just because XML configuration is seen as complex and verbose, this doesn't mean that we should switch everything over to annotations. Everything in moderation, otherwise we'll be campaigning for the return of the web.xml file in a couple of years! ;-)

Comments

• Simon,
  Touching on your security concerns, I would like to offer the perspective of someone who is working in the IT department of a company that has many departments and lots of trading partners.
  Our environments are heterogenous... any "Java only" security models just are not going to cut it.
  Policies, such as self-registration, aren't done on an application by application basis, and we have to come up with mechanisms that work as well for ColdFusion as for PHP as for Java. Federated security with partners is becoming a bigger deal every day.

  I worry, perhaps wrongly, that focussing in too much on security from the servlet container's point of view might blur the larger picture.

  Can you make some suggestions on how the J2EE security model could "play nice" with external "langauge agnostic" security frameworks?

  --John

  Posted by: johnreynolds on July 15, 2005 at 07:16 AM

• +1 on regex URL patterns. This was a major source of frustration for me a year ago when I was writing a somewhat simple CMS for my employer. It could also be useful if the standard provided a way to know which servlet mapping is in use when a servlet is mapped to more than one pattern.

  Posted by: jezuch on July 18, 2005 at 08:27 AM

• John,

  I too work in environments such as large investment banks where there are heterogeneous systems, some with a single security infrastructure and some without. On the other hand, I have also worked on smaller clients where they have no need for such large security infrastructures and are happy using whatever facilities are built into the J2EE server they are using.

  As you know, J2EE applications can either make use of the "internal" declarative security mechanism or they can use an external security infrastructure with things like servlet filters controlling access to resources. I'd like to see a much more consistent approach to integrating security into J2EE applications. Many people don't use declarative security because it's too limiting. A good example here is regex support for secured resources. Another is that once you go down the declarative route, you don't have much programmatic access to the information provided by the security subsystem. For example, if your user credentials are stored in WebLogic's internal repository, how can you do implement a "reset password" feature for your app? What about self registration?

  Personally, I'd like to see three things.

  (1) Keep the concept of declarative security. I think it's a good thing since you don't have to implement your own security filters, etc. However, the way that security constraints are mapped to resources needs to be improved (e.g. regex support).

  (2) Once an app goes down the declarative security path, access control is taken care of. Again, this is a good thing but I'd like to see a much richer API for interacting with the underlying security subsystem. For example, an API to administer users, roles, reset forgotten passwords, etc. This API would be available as part of the J2EE standard and be implemented by the server vendors. For example, using this API, you could modify the contents of the tomcat-user.xml file on the fly, perhaps to add new users or reset passwords.

  (3) For real value add, the server vendors should provide a way to enable this API to be fulfilled by an external security infrastructure. For example, if a company uses Active Directory for SSO, then they should provide a bridge between the app and the security infrastructure. Therefore, from my J2EE app, I can perform operations such as self registration through the standard API. Of course, you might *not* want apps modifying corporate wide security settings, but this could be managed when integrating the server with the external security system. For example, perhaps the Java security model could be used to grant privileges to the various operations on the standard API. In effect, you could setup read/write, read only or zero access to the external security infrastructure through the API.

  While I'd like richer security features, I appreciate that they shouldn't just be implemented inside the servlet container. Instead, I'd like the servlet container (well, maybe even the J2EE server) to provide a standard API and leave the implementation details to the vendors. Perhaps this actually goes outside of the servlet spec.

  Posted by: simongbrown on July 22, 2005 at 05:16 AM

This work is licensed under a Creative Commons License.