10.1 Security Levels

Today's database applications become increasingly complex, which is a reason why JDO has been introduced to make their development simpler. On the other hand, this complexity demands a higher security level, because of higher data volumes , more users, and more complex data models. When applications provide their services and data over the Internet, a multi- tier system can process or exchange some one hundred megabytes per second. Special precautions must be made to protect sensitive data. By clever planning and partitioning into application layers , the protection overhead against reluctant access or data corruption can be reduced. The following paragraphs define the different levels or domains of security and their objectives.

10.1.1 Field- and class-level security

The Java programming language already provides some security properties, so code can be written to encapsulate data and deny foreign code access to inner data structures of classes. By using the well-known keywords "private" and "public," field, method and class access can be extended or limited. Unfortunately, there is no difference between "reading" and "modifying," so programmers often implement set () and get () methods to restrict field access. The C++ const qualifier is also missing.

The objective of field and method access restrictions is primarily to make code more structured, not to protect data access.

An example for this security domain can be found in the collections framework, java.util.Collection , and friends . Modification or deletion from collections should be prevented or at least detected while another part of the application still iterates the collection. Some collection class implementations throw a ConcurrentModificationException when this case happens. If the framework developers had allowed access to next and previous references of a list, such detection could not be implemented.

On the other hand, the JVM can provide real security by code verification and different ClassLoader instances. This kind, the so-called sandbox security, protects non-public fields and methods against foreign code. Compared to C++, a cast of some reference cannot be used for direct memory access. An exception is the Reflection API, which not only allows field access, but also provides metadata about classes. Since Java 2, the Reflection API is protected by a security policy and must be enabled for code bases that need metadata access. Special considerations must be taken to disable extension of packages by foreign code, which would withdraw package-level security. By " sealing " and signing a JAR file, the simple implementation of another class in the same package can be refused .

10.1.2 Datastore-level security

The restriction of database operations on columns , rows, tables, or even complete databases is covered by this layer of security. Database systems often implement their own user administration and group, role, and rights management. Usually, users can be assigned to groups that have a set of rights. For example, an administrator group may create or delete tables, may make backups , and so on, while the employee management may modify salaries or read other sensitive data.

Basically, the following operations are available:

• Read

• Insert

• Modify

• Delete

• Query

These operations can be applied to the following entities:

• Columns

• Rows

• Tables

• Users

• Rights/roles

• Databases

Under certain circumstances, the rights management can lead to a particular database design ”for instance, if there are no column-level access rights definable. The test of access rules can have strong performance effects and may also lead to special database designs.

Using cryptography can be necessary either to protect the data against unauthorized copying (fixed disks and backups), or it can protect data that is sent via public networks.

10.1.3 Application-level security

Implementing application-level security can create a complex, flexible and powerful access management, which can hardly be realized by Java or database-level security. A good design is important and must be able to prevent inadvertently implemented security holes. In the past years , many Web sites were found that let intruders execute SQL code directly from outside. Some developer had overseen a niche where the JDBC user/password pair could be somehow tracked. Often, this security hole is introduced by String operations in the code instead of a reasonable encapsulation ”for instance, when input parameters are put into SQL queries.

Essentially, JDO provides an outstanding option to implement application-specific security checks by transparent persistence. A user/group/rights management or access control list can be implemented in short time.

Role-based security is also provided by the J2EE authentication concept and access restrictions can be declared for EJB interfaces on a method-level. How JDO and J2EE work together in a secure context is explained later.