Catching up on the homework for the free J2EE Programming Class I’m taking, this week drills down into the security options offered by servlet containers, specifically Tomcat. One of the things I hadn’t spent much time on before was the declarative security functionality that exists (apparently) in all servlet containers. Unlike ColdFusion and ASP, servlet containers (and thus Tomcat) give system administrators (not the developer) the ability to create password protected directories, ‘realms’ and users that access the directories within a specific realm. All the administration is done within the web.xml file of your web application. Here’s an example:

<web-app>
 <!– … –>
 <security-constraint>
   <web-resource-collection>
     <web-resource-name>Sensitive</web-resource-name>
     <url-pattern>/sensitive/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
     <role-name>administrator</role-name>
     <role-name>executive</role-name>
   </auth-constraint>
 </security-constraint>
 <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/login.jsp</form-login-page>
        <form-error-page>/login-error.html</form-error-page>
    </form-login-config>
 </login-config>
 <!– … –>
</web-app>

The above locks down the ‘/sensitive/’ directory (and everything inside it) to users in the administrative and executive realms and forces anyone and everyone trying to access said directory to login using /login.jsp.

Couple benefits that I see to this idea of declarative (rather than programmatic) security:

a) administration chores are handled by system administrators, no developer intervention is required outside of setting up the login pages.

b) According to this article, “.. J2EE compliant servlet containers are required to track authentication information at the container level (rather than at the web application level)” which means that if you setup multiple websites on a J2EE compliant servlet container, you get single sign on to all the applications running on that servlet container. Very cool.

c) Very little coding is required of programmers, giving them more time to focus on the applications they’re building, this also means fewer bugs.

Interested in reading more?

Declarative Web Application Security with Servlets and JSP: http://www.informit.com/isapi/product_id~%7B116C8D3F-BE60-47A3-B8EC-EF132654A5A3%7D/content/index.asp

Tomcat 4 Servlet/JSP Container Realm Configuration: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html

Tomcat 4 Single Sign On: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/host.html

JRUN Security (no mention of any declarative security functionality): http://livedocs.macromedia.com/jrun4docs/JRun_Administrators_Guide/authentic.jsp

The JavaTM Web Services Tutorial: Web-Tier Security: http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebAppSecurity4.html