Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 14: Tomcat Security 2. Close your browser and start a new instance, and then try to access the managersystem application using the new user joe. The UserDatabase has been updated, and the authentication succeeds, without the need to stop and start the Tomcat server. In the approach detailed here, the username and password used for authentication are stored on the server in plaintext. The next section describes how to secure a file-based Realm. Securing a File-Based UserDatabase Realm A UserDatabase Realm can be configured in a more secure manner than previously illustrated. While UserDatabase can be made reasonably secure, the ideal solution for secure authentication is to use an alternative Realm (JDBC, JNDI, or JAAS), which is discussed shortly. The UserDatabase Realm stores passwords in cleartext in the tomcat-users.xmlfile. This is not very secure. Therefore, a way must be found to store these passwords in a less readable format. Use the following steps to configure UserDatabase in a secure fashion: 1. Select the password digest algorithm. 2. Create a digested password. 3. Add the digested password to the Realm. 4. Test the digested password. Selecting the DIGEST Algorithm The choice of a digest algorithm is limited to those supported by the java.security.MessageDigest class (typically SHA or MD5). To choose one, the digestattribute of the element in the $CATALINA/conf/server.xml file must be set. In this example, SHA is used: When a user enters a password at the authentication stage, Tomcat digests it with the algorithm specified here and then compares it with the value stored in the authentication file. Creating a DIGESTed Password A digested version of the password must now be created. Tomcat comes with a script ( digest.shon Linux; digest.bat on Windows) located in $CATALINA/binthat calculates digests. The algorithm to use (SHA in this case) and the string to digest ( tomcat, which is our password) must be specified as parameters: $ $CATALINA_HOME/bin/digest -a sha tomcat tomcat:536c0b339345616c1b33caf454454d8b8a190d6c The output (highlighted in bold) is the string entered, followed by a colon and the SHA hash needed. Adding the DIGESTed Password to the UserDatabase Realm The final step is to add the digested password to the UserDatabase Realm for the Tomcat installation. This is accomplished by copying the digested output of the preceding step and adding it as the passwordattribute of a user in tomcat-users.xml:

For reliable and cheap web hosting services please check cheap web hosting website.

Chapter 14: Tomcat Security File-Based Realm: UserDatabase A file-based Realm maintains its authentication data in flat files. These files can be edited using a normal text editor. The data is kept in human-readable format (such as XML). The primary built-in file-based Realm implementation for Tomcat 6 is called UserDatabase. UserDatabase reads authentication data from a specified XML file for use by Tomcat 6 during startup. This realm also has the following properties: . The data in the Realm can be programmatically changed during the lifetime of the engine. This enables various possibilities for building administrative utilities. . UserDatabase is persistent. That is, upon modification and shutdown, the UserDatabase can also persist any changes back to its associated XML ( tomcat-users.xml) data file. . The admin(not yet available with TC6) utility supports the graphical editing of authentication data within a UserDatabase Realm. The UserDatabase realm is an integral part of Tomcat 6 s authentication and programmatic security support. Configuring UserDatabase In the default server.xml (in the Tomcat 6 server distribution), the UserDatabase Realm is already configured. The UserDatabase is typically configured in the element as a JNDI Resource. Here is a typical configuration: This makes the UserDatabase accessible from an application via JNDI lookup, relative to the java: comp/env naming context. Furthermore, it also provides an easy reference in a later scope. For example, you can use the UserDatabase as a Realm at the container level by adding the following definition: In fact, this is precisely the content of the default Tomcat 6 server.xmlfile. This means that both the managerapplication and the host-manager system applications actually rely on UserDatabase as the Realm for authentication. To see how UserDatabase is a modifiable, updateable Realm, use a text editor to add a new user/ password entry: 1. Find the $CATALINA_HOME/conf/tomcat-users.xmlfile and add the following entry using the text editor:

For high quality java hosting services please check tomcat web hosting website.

Chapter 14: Tomcat Security Security Realms The authentication mechanism descriptions detailed how the credentials used for the authentication process (for example, username and password) are obtained. However, for authentication to take place, Tomcat must also have access to the real credentials against which those sent from the browser must be compared. This section describes where Tomcat stores the actual credentials on the server and how it obtains them. Realms are the standard mechanism used for storing the credentials used by Tomcat to authenticate the client. Tomcat s Realm mechanism is an implementation of the Realm support mandated in the Servlet specification. A Realm is a standard programming interface defined in Tomcat for accessing a user s username, password, and roles. Tomcat 6 s built-in default authentication implementations (including the login mechanisms for the manager utility and the Single Sign-on Valve) depend on Realms to authenticate the user. Users and Roles The Web application security model is built around the concept of users and roles. Users are assigned to a role, which determines the resources that the user is allowed to access. For example, a Web application can declare that the resource /admin can be accessed only by users belonging to the admin role. Then, a Realm can be configured to consider the users alice and bob as belonging to the admin role. Thus, when alice and bob authenticate, they will be allowed access to /admin. The advantage of roles is that they enable the Web application to be configured independently of the permissions of the users who access the application. Using the preceding example, the deployment descriptor of the application needs to specify only that a manager role is required, and is not concerned with the identities of the users who are allowed access. The actual mapping of users to roles can be specified at deployment time and can be changed dynamically without having to change the application code. This clean separation of the authentication code from the actual method of authentication is the main advantage of Realms. This separation allows for many different ways of creating Realms. The following four built-in Realm implementations can be deployed with Tomcat 6: . File-backed, in-memory Realms . JDBC Realms . JNDI-based Realms . JAAS-based Realms In addition to these built-in Realms, it is also possible for developers to create custom Realms supplying the authentication data via arbitrary custom means. The following sections provide detailed coverage of each of the built-in Tomcat 6 Realm implementations. Where applicable, a basic deployment configuration is first described to familiarize you with the particular Realm implementation, followed by the presentation of a more secured method of deployment.

For high quality java hosting services please check tomcat web hosting website.

Chapter 14: Tomcat Security The element is used to specify how users authenticate with the Web application. determines which of the authentication mechanisms described here is used. Possible values include BASIC, DIGEST, FORM, and CLIENT-CERT. Because we ve chosen FORM, the
element must be nested in the element.
identifies which page in the Web application is used to authenticate the user ( /login.jsp) and which page is displayed when authentication fails (/notAuthenticated.jsp). No page is configured to be displayed when authentication succeeds. Instead, the user is presented with the URL that triggered the authentication in the first place. Authentication Form In the preceding example, the URL /login.jspis used to specify the login form. While any valid HTML page containing an HTML form may be used, the HTML form used to send the credentials to the server must be configured in three specific ways: . The value of its

The error page, named notAuthenticated.jsp, can contain any HTML that conveys to the user the fact that the authentication attempt failed. You should also create a page named index.jspthat contains the fictitious main page of the application. This page is shown if your authentication is successful.

If you looking for unlimited one inclusive web hosting plan please check cheap web hosting website.

Chapter 14: Tomcat Security The HTTPS client certificate mechanism is, of course, quite secure. If the public key architecture upon which HTTPS client authentication is based were defeated, the very basis of secure e-commerce would fall with it. Beyond this apocalyptic scenario, however, are some potential weaknesses: . Key length: The most important factor in the security of public key encryption is the length of the key used to encrypt the messages. As computing evolves and computing power increases, ever larger keys will be needed to maintain security against brute force hack attempts. Administrators should stay informed about public key architecture issues and upgrade the keys used should this become necessary in the future. . Theft: The fundamental assumption of public key authentication is that the corresponding private key is available only to the trusted party. Should the private key be stolen, the authentication would be compromised. While quite secure, the HTTPS client certificate mechanism is rarely used outside of business-to-business applications because of the complexity of the process one must go through (and associated cost) to obtain a certificate for each authenticating client. Configuring Authentication In order for a Web application to use one of the authentication mechanisms just described, it must be configured to do so inside its deployment descriptor ( web.xmlfile). This is accomplished by adding and elements to the element. These elements are discussed in Chapter 7 . An example of their use is shown here: Entire Application /* manager FORM My Application
/login.jsp /notAuthenticated.jsp … manager In this code excerpt, the element is used to define a portion of the application that is restricted to users belonging to a specific role. The element uses URL pattern matching to determine the protected portion of the application (in this case, the entire application), and the element is used to restrict that portion of the application to authenticated users who belong to the user role. For more information on roles, see the section Users and Roles, later in this chapter.

For reliable and cheap web hosting services please check cheap web hosting website.

Chapter 14: Tomcat Security A hashing algorithm takes some data as input and from it creates a unique fingerprint (which is usually 16 or 20 bytes long). This is a one-way process, meaning that the digest cannot be undigested to discover the original data. Because each fingerprint is unique, the digest of the original data can be compared with a digest of a second set of data. If the digests match, then the second set of data is proved to be identical to the original digest of data. If two sets of data are purported to be identical, they are confirmed as such. This process can be applied to passwords by digesting the password and storing its digest in a file or database. Thus, even if the stored password digest is compromised, an attacker cannot undigest the password the hash represents, and it is thus unusable. To determine whether a user has entered the same password, the user s password is digested and compared with the digest value on file. If they match, it is the same password. Java supports two digest algorithms: . MD5: This algorithm is used in several password-storage mechanisms, including many Unix systems. MD5 produces a 16-byte (128 bits) message digest. . SHA: This algorithm is more secure than MD5 and produces a 20-byte message digest. Form In form-based authentication, the browser does not knowingly cooperate in the authentication process. Instead, the Web application creates an HTML form wherein the form name and username and password fields all have special names. These fields can then be intercepted by the Servlet container, which uses the data to provide authentication. Because an HTML form can be transmitted over an encrypted connection (HTTPS), form-based authentication can be made reasonably secure. It does suffer from at least one disadvantage, however: . Reliance on usernames/passwords as credentials. While the form-based mechanism can transmit credentials after they have been encrypted with HTTPS, the authentication mechanism is still reliant on passwords, which can be defeated either by brute force or by social engineering. HTTPS Client Certificate When a browser establishes a secure connection with a server, the browser is sent a public key certificate from the server. This certificate enables the browser to authenticate the server. That is, it enables the browser to know the true identity of the server as certified (signed) by a trusted third party (such as VeriSign). This authentication mechanism enables the browser to be certain of the identity of the server, so that sensitive transactions such as e-commerce can be conducted. Note, however, that this process is asymmetric; the server does not receive a certificate from the client. The HTTPS client certificate mechanism upgrades this process to be symmetrical. With this mechanism, the Web browser transmits a public key certificate to the server, which can then use the certificate to authenticate the client. Both parties, therefore, are authenticated with each other. Note, however, that most server-based applications rely on simpler mechanisms to authenticate their clients (such as an HTML form-based mechanism).

For high quality jboss hosting services please check jboss web hosting website.

Chapter 14: Tomcat Security Authentication Mechanisms Servlet-based applications have four standards-based authentication mechanisms from which to choose: . BASIC . DIGEST . Form . HTTPS Client Certificate A brief description of these mechanisms follows. We demonstrate their use later in the chapter. BASIC As its name implies, the BASIC authentication mechanism is simplistic. The browser sends base64encoded credentials to the server, which then decodes them and uses them to authenticate the user. This mechanism has two somewhat serious problems: . Base64 encoding is not secure. Base64 is intended as a means of encoding binary data as ASCII data for transmission via protocols that lack support for binary data. It is not a type of secure encryption mechanism. In the case of the BASIC authentication mechanism, base64 is better than sending credentials in plaintext, but not much better. . Browsers cache credentials after authentication. Once a user authenticates, there is no way for the user to log out other than by exiting the browser or if the server times out the session because of inactivity. This disadvantage also applies to the other browser-managed authentication mechanisms, such as DIGEST and HTTPS Client Certificate. Nevertheless, despite its insecurity, BASIC remains a good option for a simple level of security designed to keep out the mindless hordes. When administrators really don t care if the protected resource is compromised, BASIC is not a bad mechanism to use. DIGEST DIGEST is a step up from BASIC. Another browser-based mechanism, DIGEST is very similar to BASIC with the exception that the password is transmitted in a secure fashion. The browser performs a digest on the password (a digest is a one-way hash, as explained shortly) and transmits the digest to the server. The server then digests the password to which the browser-provided password digest will be compared, and if the two match, the authentication is successful. DIGEST is reasonably secure, but it too suffers from two flaws: . In Tomcat, the original password must be stored somewhere in plaintext. This is especially unfortunate when the password is stored in a file, as it can then be viewed by anyone with access to that file on the server machine. (A workaround is possible using file permissions to secure access to the file.) . It has the same cached credential problem that BASIC has. (See the preceding section, BASIC, for details.) A digest, also called a hash, is used to provide proof that a set of data hasn t been nefariously (or unintentionally) altered.

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 14: Tomcat Security In addition, by default, all Java applications do have read access to the directory in which they are located, including its subdirectories. Securing Web Applications The previous sections have been concerned with securing the Tomcat server instance, the underlying operating system resources, and the Java platform. Up until this point, you have not examined any techniques to secure specific Web applications running in the Tomcat instance. In this section, we consider techniques for securing individual Web applications. These techniques fall under the following categories: . Authentication and Realms . Encryption . Host Restriction Note that these techniques can also be applied to Tomcat s built-in system applications. The techniques described here are often called declarative security measures. They are declarative because you apply them by modifying XML configuration files, typically the application s web.xmlfile, and apply them declaratively. This is in contrast to programmatic security, in which Java coding is used within a Web application to perform security checks. Both of these terms are official Java EE terminology and concepts. As an example of programmatic security, a sensitive Web application can check, using Java coding, to make sure that any user accessing itself must have the role of manager (or higher) before allowing access. An in-depth discussion of declarative security is beyond the scope of this blog, but any Java EE 5 book should have in-depth exploration into programmatic security. Note that many applications designed for running in Tomcat do not enforce programmatic security, and do not use declarative security in their web.xml file. These applications, for the most part, are vulnerable. You can add a minimal level of security by enforcing user authentication via the techniques shown in this section. Authentication and Realms Authentication is the process of determining and validating the identity of an application s client. The Servlet specification provides integration with the Java Authentication and Authorization Service (JAAS) API. This enables Web applications to authenticate their users in a standard way that is portable across different Servlet containers. Some Java developers have been known to eschew open standards in favor of their own. It is entirely possible (and indeed somewhat common) for Servlet developers to authenticate users via some homegrown mechanism, rather than via the JAAS/Servlet standard mechanism discussed subsequently in this section. System administrators should be aware that in such circumstances, this section will be of little utility. Tomcat provides a Realm mechanism, mandated in the Servlet specification, to assist Web applications in the implementation of user authentication. Essentially, Realms hold authentication information that can be accessed via either programmatic security, or via declarative security (configuration files). Details of the available Realms are explored later in this chapter.

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 14: Tomcat Security Enabling Creation of a Class Loader The following example shows how to give a specific Web application, yourWebApp, the capability to create a class loader: grant codeBase file:${catalina.home}/webapps/yourWebApp/WEB-INF/classes/- { permission java.lang.RuntimePermission createClassLoader ; }; Enabling JDBC Drivers to Open Socket Connections to Databases The following example shows how to allow all Web applications access to a specific database running on the host db.server.comon port 54321: grant codeBase file:${catalina.home}/webapps/- { permission java.net.SocketPermission db.server.com:54321 , connect ; }; Note that the preceding example allows all code across all of your Web applications to connect to db.server.com:54321. If this is too much of a security risk, the JDBC driver can be explicitly granted permission individually: grant codeBase file:${catalina.home}/webapps/webAppName/WEB-INF/lib/ mysql-connector-java-5.0.4-bin.jar { permission java.net.SocketPermission db.server.com:54321 , connect ; }; Sending E-Mail with JavaMail Sending e-mail requires that a Web application have access to port 25 on an SMTP server. The following example shows how to grant this permission to all classes in a Web application: grant codeBase file:${catalina.home}/webapps/myWebApp/WEB-INF/classes/- { permission java.net.SocketPermission mail.server.com:25 , connect ; }; Reading or Writing to Files Outside of the Web Application s Directory Earlier in this chapter, we discussed securing the file system. If the file system has been properly secured, the following grant can be used to give Web applications full access to the file system (and thus rely on the operating system to enforce permissions): grant { java.io.FilePermission <> , read,write,execute,delete ; }; While it may be tempting to use the Java Security Model in place of securing the file system via operating system permissions, such a tactic is unwise. Relying on the operating system provides an important extra layer of security in the event that the Java Virtual Machine itself becomes compromised and exploited. Additionally, in many configurations, it is likely that Tomcat is not the only exploitable network service on the server another good reason to utilize the operating system s security model, as Tomcat s security settings would not apply to the other services.

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.

Chapter 14: Tomcat Security // Precompiled JSPs need access to this package. permission java.lang.RuntimePermission accessClassInPackage.org.apache.jasper .runtime ; permission java.lang.RuntimePermission accessClassInPackage.org.apache.jasper .runtime.* ; }; Note that system administrators are not only free to modify Tomcat s policy file, they are encouraged to do so. Once the Security Manager has been enabled, it s likely that changes to it will be required in order for certain aspects of deployed Web applications to function. Recommended Security Manager Practices You have explored the process of enabling the Security Manager with Tomcat, and are familiar with the location of Tomcat s policy file. The following are recommended practices for granting permissions to applications. These techniques prevent tampering of the underlying operating system, other machines on the network, and the Tomcat server instance, from potentially malicious Web applications. Using the Security Manager If the Security Manager is not used with Tomcat, any JSP or class file in a badly written or malicious Web application is free to perform any action on the server machine that it desires. This includes opening unauthorized connections to other network hosts, writing to the server file system where is shouldn t, or abnormally terminating Tomcat itself by issuing the System.exit(n)command. Clearly, to maintain a secure Tomcat installation, the Security Manager should be enabled, and fine- grained permissions should be set. Understanding Application Requirements If Tomcat s default policy file is enabled, Web applications are likely to be unable to perform certain required functions. Consider the following tasks that are unauthorized with Tomcat s default policy configuration: . Creating a class loader . Accessing a database via a socket (for example, the MySQL JDBC driver trying to establish a connection with a MySQL database) . Sending an e-mail via the JavaMail API . Reading or writing to files outside of the Web application s directory There are a myriad of permissions that an application may require. System administrators must communicate with the application developers to understand which permissions the Web applications will require. Examples for enabling some of the common permissions listed here are reviewed in the next section. To learn about other permissions, review the Java Security documentation links provided earlier in this chapter.

If you looking for unlimited one inclusive web hosting plan please check web hosting plan website.