This week's book giveaways are in the iOS and Features new in Java 8 forums. We're giving away four copies each of Barcodes with iOS: Bringing together the digital and physical worlds and Core Java for the Impatient and have the authors on-line! See this thread and this one for details.
Installed Tomcat 7 on Linux. Java ver 6. IDE: IBM Rad (Eclipse)
Currently in the process to switch from IBM Websphere to Tomcat. The web serverI am now using is IBM websphere app server 8. It comes with a GUI admin console on which I can easily config the JNDI and JDBC data source.
Now, for Tomcat, how can I config the JNDI and the JDBC Data source etc?
And just to remove any doubts, this is also the way to configure JNDI.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jul 12, 2012
Have a couple of further questions:
1) To use a Oracle JDBC driver: DriverManager.getConnection("jdbc: oracle:thin:@database","username","password");
This username and password, on the IBM Websphere, I used to specify it via JAAS property on the admin GUI. Now, for Tomcat, can I specify it in the XML file? (I do not like to code the usernamse/password in the Java program).
2) Concern the hacker attack. How easy is for the hacker to access the web server and get hold of the XML files such as server.xml and context.xml? Does the Tomcat have some way to protect it? Or it is purely up to my server hardware/software (such as server hardening) set up?
3) There is a GUI tool called Tcat to facilitate the use of Tomcat. But this tool can not be used to specify the XML files (via GUI). What is the tool generally used for?
Commercial-grade webapps should not be using DriverManager.getConnection even under WebSphere. The proper way is to set up a connection pool, have the webapp do a JNDI lookup to get the DataSource, then use the DataSource getConnection method.
If you're using a container-supplied DataSource (connection pool), then the userID and password for the connection never exist within the application WAR at all. They are defined in the connection pool specification. Which is XML in Tomcat.
Tomcat has never had a reported bug that would allow an external attacker to gain access to any of Tomcat's configuration or binary files. If you tried REALLY hard, you could probably expose them, but only by overriding a lot of defaults and totally violating configuration standards. One of the best ways to protect Tomcat resources is to use the J2EE container security facilities. User-defined login/security systems are almost invariably horribly insecure. In fact, probably 80% or more of such systems can be dodged by non-technical people in under 10 minutes.
Also, don't run Tomcat as root, either out of laziness or because only root can listen in on ports 80 and 443. Run Tomcat as a non-privileged user and if you want response from ports 80/443, use the special wrapper or proxy it with something like Apache https server.
Tomcat actually does have an admin webapp, but it's not available out of the box and I can't remember if it can handle all the configuration options that XML can.
You should be aware that the J2EE spec actually designates 2 sources of webapp configuration data. The server-independent deployment descriptor, which is the WAR's WEB-INF/web.xml file, and the server-specific deployment descriptor, which in Tomcat is the Context element (context.xml). WebSphere's console allows you to define its deployment descriptor via the console, although I'm pretty sure that there's also a way to drop in a deployment descriptor file specific to WAS. Not that it matters for this particular case.
Joined: Jul 12, 2012
Where can I get the J2EE container security facilities? Is there some guide to teach how to implement the security?
3. A container security Realm definition. The Realm defines how Tomcat (or WebSphere) confirms user identity and roles. For Tomcat, there is documentation at the tomcat.apache.org site and sample Realm definitions in the server.xml file.
Sample information for item #1 can be found in most good books on J2EE. Followed, often, alas, by sample user-defined login code
It's a little harder to find samples for application logic. The primary defence provided by container security comes from the container checking incoming URLs against secured resource URL patterns, so the application logic is never invoked for unauthorized users, but it's often useful to provide additional refinements, which can be done by the isUserInRole() method. And, of course, but invoking the getRemoteUser() method to get the logged-in user's name (it will return null if the user isn't logged in).
The easiest Realm to use in Tomcat is the MemoryRealm and its descendents, because they allow you to define userids, passwords, and security roles in a file (default TOMCAT_HOME/conf/tomcat-users.xml). This is good for testing and other lightweight security needs. Production systems usually plug-replace the Realm with one of the database or LDAP/Active Directory Realms or something like that.