9.1. Introduction

DbForm's security features are fully compliant with SUN's Java Servlet API Specifications, version 2.2. Chapter 11 of the Java Servlet Specification 2.2 describes the mechanisms containers must provide in order to enable developers and deployers to ensure the following characteristics of security:

DbForms, built on top of JSP, naturally builds on top of JSPs security concepts. Building a proprietary security system for DbForms (from scratch) would not make much sense. Building on top of implies that DbForms indeed provides an additional level of security handling.

In short, DbForms takes away much work and worries from the developer, but not from the deployer. The deployer is still concerned with defining user-groups, choosing UserManager-factory-classes, eventually setting up database tables for user name/password, etc. Many of these issues (i.e. choosing UserManager-factories) are dependent of Application Servers (which is another reason why DbForms does not address these issues).� For more information about the role of the deployer, refer to paragraph 2.2.2 of the Java Servlet Specification (Roles/Deployer)

As we have elaborated, the deployer establishes the basic infrastructure for application security. Would that be sufficient for fulfilling an application security needs? Well, the deployer could indeed provide a certain level of security, but building an application using declarative security only, will not work. Why?

Consider the following example:

We have a view called customer.jsp, accessing a table customer, and we have three users-groups A, B and C. (The terms group and role are used synonymously in this document.)

Members of A may read, insert, update and delete customers, members of B may read and update customers and members of C have no access at all.

Using declarative security a deployer could define security constraints in web.xml that allow members of A and B to access customer.jsp and deny access for C. But how should the distinction be made between A and B? One way would be to split customer.jsp into 2 files -one with a delete button and one without. But how do we prevent malicious users from simulating a delete button using telnet?

This is where DbForms security concept steps in: