10.4 Summary

From the Java language point of view, JDO does not introduce any security gaps. The PersistenceCapable interface is well designed, optimized for speed, and effectively requires the same security checks as Java Reflection does. The JDO programmer is not forced to implement any public set/get methods or to derive from an abstract persistence class. On the other hand, an application developer needs to keep in mind that a persistent instance lets anyone access the underlying data-store connection, as long as the instance is not made transient. To prevent that, a service-oriented architecture (SOA) is required for security-sensitive applications, as explained in Chapter 9, Section 9.2.4.

From the database point of view, JDO only provides a simple username/password authentication. JDO does not define any other access control list (ACL) management. By defining fetch groups, it can be possible to read only fields of persistent instances, to which the current user is allowed. This part is completely unspecified by JDO.

Lastly, J2EE managed environments (Servlet, EJB) or application-specific access implementations provide a greater flexibility. They can be used to declare access privileges on a method, class, field, or operational basis, but they require a higher implementation effort.