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.
�C�digo Privilegiado
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.
�Propiedades de Entorno
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.
�Seguridad en Red
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.