Declarative security (Chapter 7) offers a number of advantages to the developer. Chief among them is the fact that individual servlets and JSP pages need no security-conscious code: the container (server) handles authentication in a manner that is completely transparent to the individual resources. For example, you can switch from form-based authentication to BASIC authentication or from regular HTTP connections to encrypted HTTPS connections, all without any changes to the individual servlets or JSP pages.
Even when you want a bit more control than just “access allowed” or “access denied,” it is convenient to let the server maintain and process the usernames and passwords, as discussed in Section 8.1.
However, the convenience of container-managed security comes at a price: it requires a server-specific component. The method for setting up usernames, passwords, and user roles is not standardized and thus is not portable across different servers. In most situations, this disadvantage is outweighed by the faster and simpler servlet and JSP development process that results from leaving some or all of the authorization tasks to the server. In some cases, however, you might want a servlet or JSP page to be entirely self-contained with no dependencies on server-specific settings or even web.xml entries. Although this approach requires a lot more work, it means that the servlet or JSP page can be ported from server to server with much less effort than with container-managed security. Furthermore, it lets the servlet or JSP page use username and password schemes other than an exact match to a preconfigured list.
HTTP supports two varieties of authentication: BASIC and DIGEST. Few browsers support DIGEST, so I’ll concentrate on BASIC here.
Here is a summary of the steps involved for BASIC authorization.
If you care about the details, base64 encoding is explained in RFC 1521. To retrieve RFCs, start at http://www.rfc-editor.org/ to get a current list of the RFC archive sites. However, there are probably only two things you need to know about base64 encoding.
First, it is not intended to provide security, since the encoding can be easily reversed. So, base64 encoding does not obviate the need for SSL (see Section 7.5) to thwart attackers who might be able to snoop on your network connection (no easy task unless they are on your local subnet). SSL, or Secure Sockets Layer, is a variation of HTTP where the entire stream is encrypted. It is supported by many commercial servers and is generally invoked by use of https in the URL instead of http. Servlets can run on SSL servers just as easily as on standard servers, and the encryption and decryption are handled transparently before the servlets are invoked. See Sections 7.1 and 8.6 for examples.
The second point you should know about base64 encoding is that Sun provides the sun.misc.BASE64Decoder class, distributed with JDK 1.1 and later, to decode strings that were encoded with base64. In JDK 1.3 it can be found in the sun.misc package in jdk_install_dir/jre/lib/rt.jar. Just be aware that classes in the sun package hierarchy are not part of the official language specification and thus are not guaranteed to appear in all implementations. So, if you use this decoder class, make sure that you explicitly include the class file when you distribute your application. One possible approach is to make the class available to all Web applications on your server and then to explicitly record the fact that your applications depend on it. For details on this process, see Section 4.4 (Recording Dependencies on Server Libraries).
13.59.141.75