WebSphere Security.
You can configure security with scripting and the wsadmin tool.
Before starting this task, the wsadmin tool must be running. See the Starting the wsadmin scripting client article for more information.
If you enable security for a WebSphere Application Server cell, supply authentication information to communicate with servers. The sas.client.props and the soap.client.props files are located in the following properties directory for each WebSphere Application Server profile:
o com.ibm.CORBA.loginUserid=
com.ibm.CORBA.loginPassword= Also, set the following property:
com.ibm.CORBA.loginSource=properties The default value for this property is prompt in the sas.client.props file. If you leave the default value, a dialog box appears with a password prompt. If the script is running unattended, it appears to hang.
o com.ibm.SOAP.securityEnabled=true
o com.ibm.SOAP.loginUserid=
com.ibm.SOAP.loginPassword= Optionally, set the following property:
com.ibm.SOAP.loginSource=none The default value for this property is prompt in the soap.client.props file. If you leave the default value, a dialog box appears with a password prompt. If the script is running unattended, it appears to hang.
wsadmin -conntype RMI -port 2809 -user u1 -password secret1 If you specify user and password information on a command line and in the sas.client.props file or the soap.client.props file, the command line information overrides the information in the props file.
Note: The use of -password option may result in security exposure as the password information becomes visible to the system status program such as ps command which can be invoked by other user to display all the running processes. Do not use this option if security exposure is a concern. Instead, specify user and password information in the soap.client.props file for SOAP connector or sas.client.props file for RMI connector. The soap.client.props and sas.client.props files are located in the properties directory of your WebSphere Application Server profile
To run any command without exposing the password in the command line, use the below format command for any operation through shell.
WAS-TEST:/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin #./stopManager.sh -conntype SOAP
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/dmgr/stopServer.log
ADMU0128I: Starting tool with the Dmgr01 profile
ADMU3100I: Reading configuration for server: dmgr
ADMU3201I: Server stop request issued. Waiting for stop status.
ADMU4000I: Server dmgr stop completed.
Example: Enabling and disabling Java 2 security using wsadmin
An example of enabling and disabling Java 2 security follows:
Using Jacl:
set security [$AdminConfig list Security]
An example of this output follows:
(cells/mycell:security.xml#Security_1)
![[Version 5.1 and later]](file:///C:/DOCUME~1/delango/LOCALS~1/Temp/msohtml1/12/clip_image001.gif){kind=small}
Using Jython:
security = AdminConfig.list('Security')
print security
To enable Java 2 security:
Using Jacl:
$AdminConfig modify $security {{enforceJava2Security true}}
Using Jython:
AdminConfig.modify(security, [['enforceJava2Security', 'true']])
To disable Java 2 security:
Using Jacl:
$AdminConfig modify $security {{enforceJava2Security false}}
Using Jython:
AdminConfig.modify(security, [['enforceJava2Security', 'false']])
Using Jacl:
$AdminConfig save
Using Jython:
AdminConfig.save()
Specifies whether to enable or disable Java 2 Security permission checking. By default, Java 2 security is disabled. However, if you enabled global security, this automatically enables Java 2 security. You can choose to disable Java 2 security, even when global security is enabled.
When Java 2 Security is enabled and if an application requires more Java 2 security permissions then are granted in the default policy, then the application might fail to run properly until the required permissions are granted in either the app.policy file or the was.policy file of the application. AccessControl exceptions are generated by applications that do not have all the required permissions. Consult the InfoCenter and review the Java 2 Security and Dynamic Policy sections if you are unfamiliar with Java 2 security.
If your server does not restart after you enable global security, you can disable security. Go to your ${was_install_root}\bin directory.
Excecute the command wsadmin -conntype NONE.
At the wsadmin> prompt, enter securityoff.
Type exit to get back to a command prompt.
Now you should be able to start the server again, with security disabled. This enables you to check what might not be set correctly through the administrative console.
| Data type | Boolean |
| Default | Disabled |
| Range | Enabled or Disabled |
IBM has shipped several versions and editions of WAS. In the first beta versions, WAS was called Servlet Express.
What started it all in June, 1998. Really only a servlet engine at that point.
In this version IBM adds JavaBean and CORBA support. Now supports Linux. Comes in two editions: Standard Edition (SE) and Advanced Edition (AE).
This version of WAS was compatible with a JDK 1.2, J2EE 1.0 version. IBM provided many enhancements to the basic J2EE 1.0 spec. Support for OS/400 (now i5/OS) and OS/390 (now z/OS) was added, although the z/OS version maintained a substantially separate codebase until v5.x. Version 3 is distributed in three editions: Standard Edition (SE), Advanced Edition (AE), and Enterprise Edition (EE).
This version was shipped in following editions:
This was a J2EE 1.2 certified application server. It inherited the database-based configuration model from V3.x for all but the single-server edition, which already used an XML datastore.
The version released on 19 November 2002. This was a J2EE 1.3 certified application server. It was a major rewrite of the V3/V4 codebase and was the first time WebSphere Application Server was coded from a common codebase. Now WAS across all deployment platforms, from Intel x86 to the mainframe, are substantially the same code. The database-based configuration repository was replaced with a replication XML file-based configuration repository. A service called the Deployment Manager had the master copy of the cell configuration, and nodes had the file(s) they needed copied from this master server whenever they changed. V5 also included a miniature version of MQ 5.3 called the embedded Java Message Service (JMS) server.
Released 1 April 2004.
Version 5.1 for z/OS is the first to support zAAP engines.
This is the follow on product to WebSphere Application Server Enterprise Edition V5.0. The workflow engine was updated to support BPEL rather than the proprietary FDML format used in V5.0. The product was also repriced and available on all IBM platforms from the Intel environments to the mainframe.
For more information please reference the #WebSphere eXtended Deployment section below.
Code based on Apache Geronimo project
Many programming model extensions previously found in WebSphere Application Server V5.0 Enterprise Edition were moved out of enterprise and into Express and Base. These APIs included application profile, startup beans, the scheduler, and async beans.
The JMS engine, now called "WebSphere Platform Messaging," was rewritten in 100% Java and its functionality greatly enhanced. (Quite obviously WebSphere MQ is still supported as the JMS provider and is interoperable with WebSphere Platform Messaging.)
The clustering was rewritten to use the high availability manager. This manages all singletons in the WebSphere environment and can provide hot recovery for those singletons.
WebSphere was modified so that a shared file system can be used to store transaction logs and this meant that any cluster member with that shared file system mounted can hot recover in-doubt XA transactions with no external HA software.
The Deployment Manager's role was eliminated from all clustering runtime operations. It's only required for centralized JMX admin and config changes.
Now supports running mixed version cells (V5 to V6) in production.
Provides the same core functionality as ND, since it shares a common programming model, but still contains the platform advantages such as:
WAS XD as its known increases the functionality of your application server in two main areas - Manageability and Performance. It also alows you to work in new ways that have never been possible before. This includes dynamic virtualisation between pools of app servers.
Under the performance header the ObjectGrid component was added, which is a standalone distributed cache that can be used with any app server (any version with a 1.4 JDK) or with any J2SE 1.4 runtime, including zLinux and z/OS support.
With Version 6, some of the functions previously found in WebSphere Business Integration Server Foundation (WBISF) moved into the new WebSphere Process Server. Others moved into the other editions (Express and above).
This version was released in May 2006, it is a J2EE 1.4 compliant application server. Functions that are delivered in this release includes:
The WebServices Feature Pack was delivered as a beta in October 2006. A feature pack is an optionally installed piece of function that can be installed on a release of WebSphere that currently exists in customer shops, in this case the WebServices Feature Pack runs on WebSphere 6.1.
The Beta release of the Web Services Feature Pack is an early implementation that does not contain all of the functionality planned for the final version. Functionality that is delivered in this Beta release includes:
The beta release can be found at https://www14.software.ibm.com/iwm/web/cc/earlyprograms/websphere/wsvwas61/download.shtml.
WebSphere Application Server V6 Extended Deployment Edition (WebSphere XD) was released in 2006 as an add-on for WebSphere 6. XD provides advanced features for both administrators who manage multiple J2EE-based applications and developers building advanced applications that require asymmetric clustering techniques. It also has a number of technologies to significantly increase the performance of applications run, including an in memory Database cache and a highly advanced load balancer called the On Demand Router.
Many businesses run multiple server farms but wish to consolidate them into a single smaller server farm. This is because most server farms are underutilizied or over provisioned. The boxes are typically running at 10% load which is quite costly and is not flexible. For example, one server farm goes hot and maxes out while the farm in the next room is still basically idle at 10%. XD allows administrators to define a single cluster (a node group) then monitor the workload and dynamically decide which boxes in the node group should host which application in order to meet these goals. If application A has a current response time of 1.5 seconds, XD will move resources away from applications B and C to increase the power dedicated to A and decrease its response time. XD can also predict that A will likely exceed its response time in 10 minutes based on a trend and react in anticipation of the event. This greatly simplifies the life of an administrator and allows the machines to be more efficiently used than a conventional multiple, independent farm of farms approach. XD also offers options to generate various email alerts when conditions are exceeded, it can restart servers when they appear to have a memory leak or after X requests.
Traditional J2EE applications work well for a large class of applications. The class can broadly be categorized as applications that run in a stateless symmetric cluster in front of a database:
There are other applications that do not work well in such an environment, for example, an electronic trading system in a bank. Such applications typically use tricks that can greatly improve performance such as partitioning, multi-threading and write through caching. These are applications that can exploit asymmetric clustering. An asymmetric cluster is practically the opposite of a symmetric cluster:
WebSphere XD offers a new set of APIs called the WebSphere Partition Facility (WPF). These APIs allow applications that require an asymmetric cluster to be deployed on a J2EE server.
The ObjectGrid is the first piece of the IBM distributed caching framework. V6 of XD shipped with support for local Java Object caching as well as peer to peer caching with asynchronous data push/invalidation. It is designed as a small footprint, to install customer extensible framework for caching objects. All aspects of the core framework have plugin points. This allows customers to add function as well as allow IBM to extend it in future product levels. It's designed to run independent of WebSphere. This doesn't mean it doesn't integrate with WebSphere 6.0 XD, it does. But, it will also work on older versions of the application server, tomcat servers, and competitive application servers. It's intended to compete against the other distributed cache products on the market. It currently requires only a 1.4 level JDK from any vendor. Version 2 of the ObjectGrid is currently under development for shipping in XD 6.0.1. It will add significant function to the component as well as widen JDK level support. The intent is to allow customers to build large grids of JVMs into which they can connect applications and store objects at various qualities of service. The grid is being designed to scale to 1000s of JVMs and hold a large quantity of data. qais