By default, you need to supply the ID and password when starting up/shutting down the deployment manager, node or application server. Example of the command as below

Deployment Manager
//bin/startManager.sh -username XXX -password XXX

Node
//bin/startNode.sh -username XXX -password XXX

Application Server
//bin/startServer.sh -username XXX -password XXX

The steps to encrypt the password and ID is as follows.

Insert the ID and password in clear text into the SOAP properties file at //properties/soap.client.props.

# grep SOAP.login soap.client.props | grep -v “#”
com.ibm.SOAP.loginUserid=wasadm
com.ibm.SOAP.loginPassword=wasadm
com.ibm.SOAP.loginSource=prompt

We use the IBM provided script to encode the password.

//bin/PropFilePasswordEncoder.sh //profiles/default/properties/soap.client.props com.ibm.SOAP.loginPassword -Backup

Taking a look at the same property file again, the password is now encrypted.

# grep SOAP.login soap.client.props | grep -v “#”
com.ibm.SOAP.loginUserid=wasadm
com.ibm.SOAP.loginPassword={xor}Es4zPjwS
com.ibm.SOAP.loginSource=prompt

Now, we can start up websphere and shut down without using the password.

su wasadm -c “//bin/startManager.sh”
su wasadm -c “//bin/startNode.sh”
su wasadm -c “//bin/startServer.sh ”

su wasadm -c “//bin/stopManager.sh”
su wasadm -c “//bin/stopNode.sh”
su wasadm -c “//bin/stopServer.sh ”
end.

======================

Some trival.
How come IBM prefers to use XOR instead of some stronger algorithm like how weblogic uses 3DES? XOR is good enough only to prevent casual snooping.

Someone demonstrated that with a online decoder

http://www.poweredbywebsphere.com/decoder.html

WebSphere applications are assigned to virtual hosts during installation and configuration process.

The virtual hosts are bound to one or more aliases (host names and ports), allowing a single application server to respond to multiple inbound request formats.

The virtual host aliases that are configured within WebSphere define the pattern match possibilities for which WebSphere application server will respond with data.

For example, if we have 7 aliases defined for a given virtual host ‘foo-app’ on application server, ‘fooserver?.

Virtual Host: ‘foo-app’
Hostname Port
thisport 8080
thatport 8081
secureport 8443
secureport2 9443
otherport 10001
otherport2 10002
otherport3 10003

Hence, for any inbound request for ‘foo-app’, if the URL does not match against the list above, the request is denied, else the client gets the access. The Application Server is the gatekeeper here.

Usually all default application server ports are removed from the ‘default_host’ virtual host once you do some ‘hardening’, forcing all inbound requests to be channeled through a proxy mechanism.

Hence, you will not be able to access the application ‘foo-app’ directly, if the default listening port is not in the list above. e.g. ‘foo-app’ listens on 1234. To get to ‘foo-app’, you need to get through the aliases above to get to ‘foo-app’.

I use Apache in the web layer above Websphere Application Server. Need to install the Websphere Proxy-Plugin and generate the xml file.

When client access the URL, the GET request reaches Apache, which then checks the request against the Websphere Proxy Plugin for the host or virtual host corresponding to the requested URL.

The Websphere Proxy Plugin has a list of valid WebSphere virtual hosts and virtual-host associated resources. Here, if matched, those requests are forwarded to the appropriate WebSphere application server. If not matched, 404 is generated.

Login to the Admin Console of the running server, i.e. Window -> Show Views -> Servers | right click the server -> Run Administration -> Run Administrative Console

Environment -> WebSphere variables

Find “ORACLE JDBC DRIVER PATH” Name out of the list (second page) and click its link

Set its “Value” to the “directory” (not the actual path + filename) where your ojdbc6.jar resides on your file system

We can set this path externally, either a stand alone ojdbc6.jar or find it with Oracle client packages, i.e. C:\app\\product\11.2.0\client_1

Click “Apply”, then “Save” (on top)

Back to WAS Admin Console, go to Security -> Global security

On “Authentication” panel, expand “Java Authentication and Authorization Service” -> J2C authentication data

Click “New”

Give it an Alias name, i.e. Alias_Oracle and input our current databases’ credential: User ID = your_db_username, Password = your_db_password

Click “Apply”, then “Save”

Go to Resources -> JDBC -> JDBC providers

Make sure that the right Scope has been selected, i.e. Node=DOMAINHOSTNAMENode01 or something

Click “New” to create a new JDBC provider

Step 1: Select “Oracle” from “Database type” menu | Provider type = Oracle JDBC Driver | Implementation type = Connection pool data source

Leave the “Name” as default, i.e. “Oracle JDBC Driver”

Step 2: if you have setup the ORACLE JDBC DRIVER PATH correctly, it should have the appropriate “Class path” to “ojdbc6.jar” already selected for you Step 3: Summary, click “Finish”

Go to Resources -> JDBC -> Data sources

Make sure the right Scope is selected , i.e. Node=DOMAINHOSTNAMENode01 or something

Click “New”

Step 1: Data source name = “Oracle JDBC Driver” | JNDI name = “jdbc/OracleDS”

Step 2: Select “Select an existing JDBC provider” = “Oracle JDBC Driver”

Step 3: URL = “jdbc:oracle:thin:@hostname:port:db_alias” | Data store helper class name = “Oracle11g data store helper”

Step 4: Component-managed authentication alias = DOMAINHOSTNAMENode01/Alias_Oracle

select “DefaultPrincipalMapping”

Step 5: Summary, click “Finish”

Back on “Data sources” screen, select the newly created data source and “Test connection”. If it succeeds, you are done

You can retrieve the data source programmatically:

Context initContext = new InitialContext(); dataSource = (DataSource)initContext.lookup(“jdbc/OracleDS”);

How you should force heap or thread dump using wsadmin script

Login to your machine running WAS
Navigate to
cd /profiles//bin/
Connect to deployment manager using wsadmin script
wsadmin.sh -conntype SOAP -username -password
Set object variable
wsadmin> set jvm [$AdminControl completeObjectName type=JVM,process=,node=,*]
Force heap dump
wsadmin> $AdminControl invoke $jvm generateHeapDump
In case you would like to dump threads
wsadmin> $adminControl invoke $jvm dumpThreads
Heap or thread dump will be saved to /profiles// directory with with respective naming convention

Heapdump
heapdump..phd
Threaddump
javacore..txt

WebSphere stores passwords for datasources, security aliassss, etc in an encrypted format in its configuration files. The format, called XOR (exclusive OR), is not a particularly strong encryption algorithm, probably designed just to stop casual snooping. (In contrast WebLogic uses triple-DES encryption.)

(To be precise IBM says WebSphere “encodes” paswords, not encrypts them.)

When you forget that password to your development database it can be useful to have the ability to decrypt XOR-encrypted passwords. Fortunately IBM have provided the means to encrypt and decrypt passwords in XOR format (although they probably didn’t mean to leave the code around for general use).

So lets encrypt the password “secret”:

WebSphere 5.x

> cd $WAS_INSTALL_DIR/lib
> ../java/bin/java -cp securityimpl.jar:iwsorb.jar com.ibm.ws.security.util.PasswordEncoder secret
decoded password == “secret”, encoded password == “{xor}LDo8LTor”

WebSphere 6.0.x

> cd $WAS_INSTALL_DIR/lib
> ../java/bin/java -cp securityimpl.jar:iwsorb.jar::ras.jar:wsexception.jar:bootstrap.jar:emf.jar:ffdc.jar com.ibm.ws.security.util.PasswordEncoder secret
decoded password == “secret”, encoded password == “{xor}LDo8LTor”

and to decrypt (don’t forget to prefix the encoded password with “{xor}”):

WebSphere 5.x

> cd $WAS_INSTALL_DIR/lib
> ../java/bin/java -cp securityimpl.jar:iwsorb.jar com.ibm.ws.security.util.PasswordDecoder {xor}LDo8LTor
encoded password == “{xor}LDo8LTor”, decoded password == “secret”

WebSphere 6.0.x

> cd $WAS_INSTALL_DIR/lib
> ../java/bin/java -cp securityimpl.jar:iwsorb.jar::ras.jar:wsexception.jar:bootstrap.jar:emf.jar:ffdc.jar com.ibm.ws.security.util.PasswordDecoder {xor}LDo8LTor
encoded password == “{xor}LDo8LTor”, decoded password == “secret”

UPDATE: IBM have heard the cries about poor password security and have added hooks from WebSphere 6.0.2 onwards that allow you to write your own password encryption. One step forward…