Security Considerations

Security considerations from the API user's perspective are discussed in the Miscellaneous lesson. As a service provider developer, you should be aware of the following additional considerations.
Privileged Code
The Java 2 Platform, Standard Edition, defines a security model for system administrators and users to use to dynamically configure the security policy for running applications. You should be familiar with that security model before writing any service provider code. This discussion covers some issues pertinent to service provider code but is not a substitute for your reading and thoroughly understanding the Java Security Guide.
The security model allows you to mark sections of your code as privileged by wrapping each section inside of a doPrivileged block. The system administrator or user can then grant permissions to your code separate from those that it grants to other components of the application. Because service provider code is often considered "system" code and is granted all permissions by system administrators and users, you must be careful which permissions that the service provider requests. Or more precisely, you must be careful which sections of code that you put inside of doPrivileged blocks. Otherwise, you might be introducing security holes that can be exploited by malicious applications.
In general, a doPrivileged block should not be publicly accessible. Rather, it should be accessible in the smallest scope possible, with the package-private scope being the widest recommended scope. The code inside of a doPrivileged block should perform the narrowest functionality required.
For example, you should never have a doPrivileged block for reading arbitrary system properties, accessing local files, or creating network connections. On the other hand, it might be reasonable to have a doPrivileged block for reading a specific system property, reading a specific configuration file, or creating a network connection to the local machine on a specific port number.
In general, keep the number of doPrivileged blocks to a minimum. Always ask yourself if it is reasonable for the administrator or user to know that an application requires such a permission (and therefore afforded the opportunity to deny the request) or is the action harmless enough that the provider should request the permission for the action on behalf of the application.
See the Java Security Guide for a general discussion of the Java security model and doPrivileged blocks.
Environment Properties
The Miscellaneous lesson talks about security considerations associated with environment properties. The Environment Properties section of this lesson describes how a provider should handle environment properties. The main security-related issue to note from these discussions is that, as a service provider writer, you should never return a context's copy of its environment properties. Rather, you should always return a clone or copy. This will forestall any possible tampering or accidental corruption of one of a Context instance's most important state--its environment properties.
If your context implementation is serializable, then you should avoid serializing any passwords or other security-sensitive environment properties.
Network Security
Most naming and directory services are accessed over the network. Although the data requested is protected by the server's authentication and access control mechanisms, some protocols do not protect (encrypt) the data that is sent as replies. This is not a problem particular to a client using the JNDI but rather a problem for any client accessing that service. Your service provider's documentation should describe the security implications associated with accessing its corresponding service over a network.

The Ground Rules: End of Lesson
What's next? Now you can:

Continue on in this trail to learn how to write a basic service provider.

The Ground Rules