Las consideraciones de seguridad desde la perspectica del usuario del API se explicaron en la lección Miscelánea. Como desarrolladores de proveedores de servicio, deberíamos tener en cuenta las siguientes consideraciones adicionales.

La Java 2 Platform, Standard Edition, define un modelo de seguridad para que administradores de sistemas y usuarios configuren la política de seguridad para ejecutar aplicaciones. Deberíamos estar familiarizados con este modelo de seguridad antes de escribir ningún código del proveedor de servicio. Esta explicación cubre algunos problemas pertenecientes al código del proveedor de servicio pero no es un sustituto para que no leamos y entendamos perfectament la Java Security Guide.

El modelo de seguridad nos permite marcar secciones de nuestro código como privilegiadas envolviendo cada sección dentro de un bloque doPrivileged. El administrador del sistema o el usuario pueden conceder permisos a nuestro código de forma separada de aquelos que conceden a otros componentes de la aplicación. Como el proveedor de servicio normalmente se considera código del "sistema" y se le conceden todos los permisos por parte del administrador y de los usuarios, debemos ser cuidadosos con los permisos que el proveedor de servicio solicita. O más precisamente, debemos ser cuidadosos con las secciones de código que ponemos dentro de bloques doPrivileged. De otro modo, podríamos introducir agujeros de seguridad que podrían ser explotados por aplicaciones maliciosas.

En general, un bloque doPrivileged no debería ser accesible públicamente. En vez de eso, debería ser accesible en un ámbito lo más pequeño posible, con el ámbito de package-private siendo el más amplio recomendado. El código dentro de un bloque doPrivileged sólo debería realizar la funcionalidad requerida.

Por ejemplo, nunca deberíamos tener un bloque doPrivileged para leer propiedades del sistema arbitrariamente, acceder a ficheros locales, o crear conexiones de red. Por otro lado, podría ser razonable tener un bloque doPrivileged para leer propiedades específicas del sistema, leer un fichero de configuración específico, o crear una conexión de red a una máquina local sobre un número de puerto específico.

En general, siempre debemos al mínimo el número de bloques doPrivileged. Siempre debemos preguntarnos si es razonable que el administrador o el usuario conozcan que una aplicación requiere dichos permisos (y por lo tanto evitar la oportunidad de denegar la petición) o si la acción es lo suficientemente importante como para que el proveedor deba pedir permiso para realizar la acción en beneficio de la aplicación.

Puedes ver una descripción general del modelo de seguridad Java y de los bloques doPrivileged en la página Java Security Guide.

La lección Miscelánea habla sobre las consideraciones de seguridad asociadas con las propiedades de entorno. La sección Propiedades de Entorno de esta lección describe cómo un proveedor debería manejar las propiedades de entorno. El principal problema de seguridad a observar desde esta explicación es que, un escritor de proveedores de entorno, nunca debería devolver una copia de sus propiedades de entorno de su contexto. En vez de eso, siempre deberíamos tener un clon o una copia. Esto evitará cualquier corrupción accidental o provocada del estado de una de las propiedades de entorno del ejemplar de Context.

Si nuestra implementación de contexto es serializable, deberíamos evitar serializar cualquier passoword u otras propiedades de entorno sensibles a la seguridad.

Muchos de los servicios de nombres y directorios se acceden a través de la red. Aunque los datos requeridos están protegidos por la autentificación del servidor y los mecanismos de control de acceso, algunos protocolos no protegen (encriptan) los datos que envía como respuestas. Esto no es un problema particular de un cliente usando JNDI sino que es un problema para cualquier cliente que acceda al servicio. La documentación de nuestro proveedor de servicio debería describir las implicaciones de seguridad asociadas con el acceso al servicio correspondiente a través de la red.