Working with Client-Side Security
As you know, J2EE applications are composed of components. The J2EE specification defines three main components , as follows :
In this chapter, I address the first two. EJBs are described in Chapter 28. A J2EE client may be an application client or a Web client. An application client runs in the client machine. It typically has a GUI (graphical user interface), but a command line is also possible. The application may access server-side components directly (such as EJBs) or may establish a tunnel (such as an HTTP or HTTPS) to the necessary services. The Web client has dynamic Web pages (HTML, XML and so on). These Web pages are rendered by a Web browser and are generated by the Web components that run in the Web- tier . An Applet may be embedded in a Web page.
The Web components are either Servlets or JSPs, described later in this chapter. The J2EE specification does not consider applets, server-side utility classes, and static HTML pages as part of Web components; but they are usually bundled with Web components during deployment. In addition, EJBs may be included to handle user input and business logic. Application securityAs of this writing, all Java 2 SDK system code invokes the SecurityManager method to check the policy in effect and to perform access control checks. There is a security manager for applets implemented by the AppletSecurity class, which ensures that classes are loaded only from the applet's host (or code base host). The security manager is an application-wide object. To perform some operations, classes in the Java packages ask the security manager for permission. An application can set the java.security.manager property by invoking the Java virtual machine (JVM) with -Djava.security.manager or by installing a security manager by calling the java.lang.System.setSecurityManager method. Applet securityApplets run in a sandbox by default. Recall from Chapter 26 that the sandbox is where unsigned code resides and provides a limited use of resources in the machine the code is running on. At the beginning (that is, Java 1.0), the applet was not allowed to go out of the sandbox. That restriction was good for some applications, but it was too restrictive for others. Some of the reasons why an applet may want to access local resources include the need to access a printer (for a word processor applet) or a local inventory database. Java 1.1 introduced the concept of signed applets. Applets are digitally signed to obtain extra permissions outside of the sandbox. Programs that are not digitally signed continue to be restricted by the original sandbox model. Java 1.1, however, gave unrestricted access to system resources to signed applets. It was an all-or-nothing type of access. The Extended Java Sandbox is the default model for digitally signed applets. Under the Extended Java Sandbox, digitally signed Java code is allowed to read and write to a specified directory. In that directory no executables can run, and other Java programs cannot gain access to other network services. The java.policy file (discussed in Chapter 8) provides a way to define specific permissions to the applet. This gives a finer-grained level of security. Administrators can now grant permissions based on the requestor and the resource being accessed. The problem is that the policy file needs to be modified by the end user, and this requirement is impractical . You use the jarsigner to sign a JAR. Java 1.2.1 requires that every class within the same signed JAR package needs to be signed by the same certificate because in previous Java versions, a class loaded from a signed JAR could be altered. Even if the class was altered , it could still be loaded and run but no extra permissions were granted. That provided a way to modify the behavior of the applet. Recall that to sign a JAR file you need a private key and its corresponding certificate, which can be generated by using the keytool . After the jarsigner has signed the JAR file, the signature , manifest , and digital signature files are created.
If the digital signature of the JAR cannot be verified , a security exception is thrown because the JAR has been altered. Understanding the web.xml fileThe web.xml file is where you describe how the application is configured. It is the deployment descriptor defined by the Servlet specification and, therefore, all Servlet-compliant containers support this type of file. For example, suppose that you have an application that requires some of the resources be available to only administrators. The directory structure looks something like the following:
The part of the web.xml file that supports this type of structure looks like Listing 27-1. The top element is the <security-constraint> element, which has the following subelements:
Listing 27-1: Configuring the admin directory structure using the web.xml file
<security-constraint> <web-resource-collection> <web-resource-name>AdminPages</web-resource-name> <description> The pages accessible by authorized administrators </description> <url-pattern>/admin/*</url-pattern> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <description> The roles with access </description> <role-name> admin </role-name> </auth-constraint> <user-data-constraint> <description> The user data must be transmitted via </description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint>
 Java Security Solutions ISBN: 0764549286
EAN: 2147483647 Year: 2001
Pages: 222 Authors: Rich Helton, Johennie Helton
flylib.com © 2008-2017. If you may any questions please contact us: flylib@qtcs.net |
