Welcome!

Java IoT Authors: Liz McMillan, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui, Pat Romanski

Related Topics: Java IoT, IBM Cloud

Java IoT: Article

General Best Practices for WebSphere Application Environments

Twenty-five recommendations to setting up a WebSphere environment

This article provides a list of general best practices to apply to any WebSphere Application Server V7 and V8 environment. However, some of the recommendations only apply to specific conditions and scenarios. These recommendations could be used to set up any WebSphere environment.

General Best Practices for WebSphere Application Environments

1. All WebSphere Application processes should be running as non-admin/root user.
It's not a good practice to run a process as an admin/root user. For obvious reasons, you don't want more folks to know about the admin/root password and generally the WebSphere admins are not the system admins. Create a services user account on the box and use it for the WebSphere Application's start and stop purposes.

2. Enabled Global Security.
By default, the WebSphere Application Server enables administrative security. Thus, for the most part, the infrastructure provides for reasonable authentication, authorization, and encryption of administrative traffic by default. When administrative security is enabled, the WebSphere Application Server's internal links between the deployment manager and the application servers and traffic from the administrative clients (Web and command line) to the deployment manager are encrypted and authenticated. Among other things, this means that administrators will be required to authenticate when running the administrative tools.

3. Enabled Application Security.
In addition to leveraging the application server's security for administration, it's strongly recommend that you leverage it for application security. Doing so gives your applications access to a strong and robust standards-based security infrastructure. Applications that didn't leverage application server security were typically found to have serious security holes. Designing and implementing a secure distributed infrastructure is not easy.

To enable application security, go to the global security panel and select Enable application security.

4. Configure WebSphere Security with proper LDAP repository.
WebSphere security supports different configurations, including LDAP servers, local users and local operating system levels users. However, it's recommended that you use a proper LDAP server for this purpose.

5. Leverage Administrative roles.
WebSphere Application Server allows for a variety of administrative roles depending on the version: Administrator, Operator, Monitor, Configurator, AdminSecurityManager, iscadmins, Deployer, or Auditor. These roles make it possible to give individuals (and automated systems) access that's appropriate to their level of need. It's strongly recommended that you take advantage of roles whenever possible.

By using the less powerful roles of monitor and operator, you can restrict the actions an administrator can take. For example, you can give the less senior administrators just the ability to start and stop servers and the night operators just the ability the watch the system (monitor). These actions greatly limit the risk of damage by trusting people with only the permissions they need.

6. Use HTTP Server as an interface for the Applications.
Use HTTP servers in front of an application layer, i.e., WebSphere Application. Don't allow communications directly with WebSphere's http web container port from either a load balance or from browsers.

7. HTTP and WebSphere on the Same box.
At least in higher environments, install and configure the http server on a different box than the WebSphere box. In the lower environments the same box can be used for both layers.

8. Logs on External Drive.
At least in higher environments, write the WebSphere and application log files to an external drive, so it won't fill up the server's file space.

9. Logs Archive.
Depending on the application, rotate and clean up the logs in a timely manner.

10. Read-only Logs Access for Developer.
If it's okay with the security team, grant developers read-only access for WebSphere and the applications logs on the external drive.

11. Alternate Log Access for Developers.

To enable developers to view the production application and WebSphere logs, host those shared folders from the web server instead of giving them access to those boxes. Once the logs are hosted from the web server, developers need only a web browser to view those files from their computers.

12. Log Level.
Configure log level to error in high environments. Logs in the higher environments don't need to produce unnecessary information. In the lower environments it can be set to info or debug level.

13. Leverage WebSphere Application Servers' high availability and failover capabilities.
Out-of-the-box WebSphere support high availability and failover functionality. There is no need to use any external component or product for this. One of the key benefits is that  user http session can be shared within the cluster members and, in the case of failover, the other active cluster members can resume the activity using same session.

14. Minimum Cluster Members in Cluster.
In the WebSphere clustered environment, define and create at least three cluster members. In the case of failover with two cluster members, not only the entire load will shift to one node but it also becomes a single point of failure. With three nodes, at least the load will still be distributed to two nodes and there is no single point of failure.

15. Database and WebSphere on Same box.
At least in higher environments, separate the application layer from the data layer and install them on different boxes. In the lower environments the same box can be used for both layers.

16. Use Type-4 JDBC Drivers.
Type-4 JDBC drivers don't require any component to be installed on the application layer. For the type-2 and type-3, the database's client needs to install on the WebSphere box.

17. Protect application server to database link.
As with any other network link, confidential information can be written to or read from the database. Most databases support some form of network encryption and you should leverage it.

18. Script based WebSphere Administration.
In general, it's good practice to use scripts to avoid human errors during the deployment and configuration, especially in higher environments. However, it requires an investment in time and resources to develop these scripts, especially if it is first time and / or script-based administration is not part of the current culture. Once the scripts are created, they can be used in all environments and maybe automate some of the tasks.

19. Monitoring.
Use proper application and infrastructure runtime monitoring tools that can monitor environments and application thresholds and potentially alert you to problems before they cause service interruptions.

20. EAR vs WAR Files.
According to J2EE specs, EAR file should be deployed in WebSphere. However, WebSphere does support deploying WARs and upgrade class functionality. Developers should produce EAR files from their development tool or generate EAR should it be created from the deployment scripts before deploying the application in WebSphere.

21. Don't run samples in production.
WebSphere Application Server ships with several excellent examples to demonstrate various parts of the WebSphere Application Server. These samples are not intended for use in a production environment. Don't run them there, as they create significant security risks. In particular, the showCfg and snoop servlets can provide an outsider with tremendous amounts of information about your system. This is precisely the type of information you don't want to give a potential intruder. This is easily addressed by not installing the samples during the profile creation.

22. Environments.
Generally, it's good to have more environments. Typically four would be a sufficient enough: development, QA, staging and production. Development and QA environments don't need a lot of hardware resources. It's recommended that the staging environment be a replica of production in terms of application data and hardware resources. The staging environment can also be used for stress testing and / or for production support.

23. Performance Tuning.
Tune WebSphere application servers properly for each application. Performance tuning includes optimization of a number of web container threads, JVM heap sizes, JDBC connections, OS tuning, etc. After configuring these parameters to optimize values, boost the application performance. Stress / staging environment should be used for load testing.

24. Separate your production network from your intranet.
Most organizations today understand the value of a DMZ that separates the outsiders on the Internet from the intranet. However, far too many organizations fail to realize that many intruders are on the inside. You need to protect against internal as well as external threats. Just as you protect yourself against the large untrusted Internet, you should also protect your production systems from the large and untrustworthy intranet.

25. Separate your production networks from your internal network using firewalls.
These firewalls, while likely more permissive than the Internet-facing firewalls, can still block numerous forms of attack.

Keep up-to-date with patches and fixes. As with any complex product, IBM occasionally finds and fixes security bugs in WebSphere Application Server, Virtual Enterprise, Datapower and other products. It's crucial that you keep up-to-date on these fixes. It's advisable that you subscribe to support bulletins for the products you use and, in the case of WebSphere Application Server and WebSphere Virtual Enterprise, monitor the security bulletin site for your version. Those bulletins often contain notices of recently discovered security bugs and the fixes. You can be certain that potential intruders learn of those security holes quickly. The sooner you act the better.

More information on WebSphere Application Server security, including recommendations on hardening the WebSphere Application Server infrastructure, is available on the WebSphere Application Server security page.

More Stories By Asim Saddal

Asim Saddal works in the Middleware (WebSphere Application Server, WebSphere Datapower, WebSphere Process Server, WebSphere VE) practice of IBM Software Services for WebSphere.

IoT & Smart Cities Stories
@CloudEXPO and @ExpoDX, two of the most influential technology events in the world, have hosted hundreds of sponsors and exhibitors since our launch 10 years ago. @CloudEXPO and @ExpoDX New York and Silicon Valley provide a full year of face-to-face marketing opportunities for your company. Each sponsorship and exhibit package comes with pre and post-show marketing programs. By sponsoring and exhibiting in New York and Silicon Valley, you reach a full complement of decision makers and buyers in ...
Two weeks ago (November 3-5), I attended the Cloud Expo Silicon Valley as a speaker, where I presented on the security and privacy due diligence requirements for cloud solutions. Cloud security is a topical issue for every CIO, CISO, and technology buyer. Decision-makers are always looking for insights on how to mitigate the security risks of implementing and using cloud solutions. Based on the presentation topics covered at the conference, as well as the general discussions heard between sessio...
While the focus and objectives of IoT initiatives are many and diverse, they all share a few common attributes, and one of those is the network. Commonly, that network includes the Internet, over which there isn't any real control for performance and availability. Or is there? The current state of the art for Big Data analytics, as applied to network telemetry, offers new opportunities for improving and assuring operational integrity. In his session at @ThingsExpo, Jim Frey, Vice President of S...
In his keynote at 18th Cloud Expo, Andrew Keys, Co-Founder of ConsenSys Enterprise, provided an overview of the evolution of the Internet and the Database and the future of their combination – the Blockchain. Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settl...
The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids and Smart Cities, the Industrial Internet, and more. Cool platforms like Arduino, Raspberry Pi, Intel's Galileo and Edison, and a diverse world of sensors are making the IoT a great toy box for developers in all these areas. In this Power Panel at @ThingsExpo, moderated by Conference Chair Roger Strukhoff, panelists discussed what things are the most important, which will have the most profound e...
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
Rodrigo Coutinho is part of OutSystems' founders' team and currently the Head of Product Design. He provides a cross-functional role where he supports Product Management in defining the positioning and direction of the Agile Platform, while at the same time promoting model-based development and new techniques to deliver applications in the cloud.
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
LogRocket helps product teams develop better experiences for users by recording videos of user sessions with logs and network data. It identifies UX problems and reveals the root cause of every bug. LogRocket presents impactful errors on a website, and how to reproduce it. With LogRocket, users can replay problems.
Data Theorem is a leading provider of modern application security. Its core mission is to analyze and secure any modern application anytime, anywhere. The Data Theorem Analyzer Engine continuously scans APIs and mobile applications in search of security flaws and data privacy gaps. Data Theorem products help organizations build safer applications that maximize data security and brand protection. The company has detected more than 300 million application eavesdropping incidents and currently secu...