Declarative Security for Web Application

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

3 thoughts on “Declarative Security for Web Application”

  1. I have used this in the J2EE version of CFMX with JRun. It should work as well with the standalone CFMX by just modifying web.xml

    JRun uses JAAS for authentication and authorization, you can tie it to a db, windows domain or LDAP server.

  2. Ah, the J2EE passion course. How do you like it? I did the SQL/JDBC presentation for the last class, but I noticed that Sang is not doing it this time around. I am not actively helping the class right now though…I am too busy 🙂

    How are things at MeT?

    Ted

Leave a Reply to Ted Haynes Cancel reply

Your email address will not be published. Required fields are marked *