WebSphere Application Server & Liberty

Hey WUG,

I've written several jython/python scripts to automate various configuration and admin tasks in our environment (WAS 7.0.0.21, WVE 7.0.0.2).  We have global security enabled so to run a script using wsadmin, I have to enter the WAS admin user id and password.  Ordinarily it wouldn't be a problem; however, when writing a new script it gets pretty annoying to have to enter the user id and password each time you want to test it. 

Any ideas?

Hi Script Master...sorry Danielle

  Yes it 's very easy.
 
  You need to go to WAS_HOME\profiles\PROFILE\properties.
 
  Depending on your conntype SOAP or RMI
 
   SOAP->soap.client.props
     com.ibm.SOAP.securityEnabled=true
     com.ibm.SOAP.loginUserid=ADMIN_USER
     com.ibm.SOAP.loginPassword=ADMIN_PASSWORD->you can use if want ResponseFilePasswordEncoder script to obfuscate the password and put in {xor} mode
     #Left to nothing loginSource so the properties are take from properties file
     com.ibm.SOAP.loginSource=
   
   RMI->sas.client.props
     com.ibm.CORBA.securityEnabled=true
     #In this case put properties
     com.ibm.CORBA.loginSource=properties
     # RMI/IIOP user identity
     com.ibm.CORBA.loginUserid=ADMIN_USER
     com.ibm.CORBA.loginPassword=ADMIN_PASSWORD
 
   IPC->ipc.client.props
   
     com.ibm.IPC.securityEnabled=true
     com.ibm.IPC.loginUserid=ADMIN_USER
     com.ibm.IPC.loginPassword=ADMIN_PASSWORD
     #Left to nothing loginSource so the properties are take from properties file
     com.ibm.IPC.loginSource=

    If you customize your wsadmin.properties saying conntype, ports,...you can call directly to wsadmin with out parameters only -f with your script.
    
    
    Hope this helps,

Regards,

...and finally
don't forget the below step , its very important for security reasons

profile_root/bin/PropFilePasswordEncoder.sh /profile_root/properties/soap.client.props com.ibm.SOAP.loginPassword

This will encrypt the SOAP password in soap.client.props , which is in clear text.

Joseph, Ralph,


  Thank you for explain better my comment.

  "you can use if want ResponseFilePasswordEncoder script to obfuscate the password and put in {xor} mode"

  Totally agree with Ralph, as I say ResponseFilePasswordEncoder obfuscate the password, it's not encripting really.  An is so easy to decode passwords.  So the file security permisions is the best option, to protect.


regards

Thanks for the input!!

However, my situation is a little complicated.  The company I work for is in the process of renewing its contract with the federal government.  Anyone who has been through it knows how painful the process can be.  We are currently bringing our security up to NIST standards and there are 5 other WebSphere Admins besides me.  We all use the same superuser id that WAS uses to perform specific tasks - to make a long story short, I can't add the user id and password to the WAS profile or the Enterprise Security Office will have me fired.  :-(

I was thinking more along the lines of a python wrapper script that calls the wsadmin.sh script and gets the authentication params it needs from an encrypted properties file (it would have to decrypt the properties file to grab the params and then encrypt the file when its done).  I have a shell script that does everything except encrypt/decrypt the properties file:

****************************************************************
#!/bin/sh
#
# Prompt for script name if it's not passed as parameter.
if [ $# -ne 1 ]; then
  echo '==> Enter script file name: '
  read SCRIPT
else
  SCRIPT=$1
fi

# source authfile to get credentials.
. ~/authfile

wsadmin.sh -lang jython -username $WASADM -password $WASPAS

Sorry I should have posted this one:

****************************************************************
#!/usr/bin/python

import sys

if len(sys.argv) < 2:
    name = raw_input('Script Name: ')
    print name #other stuff will go here
else:
    name = sys.argv[1]
    print name # and here, I just wanted to make sure it works :-)

sys.exit()

WOW!!!

I looked at the link and I'll say it again....WOW!!!  I think I need to do a little more research.  Because the custom property has to be added for every server and client process, it will be looked upon as a "major configuration change" which seems to get a lot people's panties in a bunch.

I'll definitely look into whether or not the password is displayed in the ps -ef output.  My thinking is, it will soften the impact therefore minimizing the amount of panick if it only needs to be implemented where the script needs to be run (namely the dmgrs).

Thanks Ralph!! The saga continues....

Danielle

Update***

Ralph, you were right.  When I run the shell script I can see the username and password being passed as if it were in the command line.    Even though the params are being passed to the script from a file, it still treats them as though they're being entered all at once.

Back to the drawing board......

As was suggested above, putting the user/password in the SOAP properties file, quasi-encrypting it, and chmod'ing to remove other-user unix access is the way to go.  I had a PMR with IBM a while back for something similar, and all they came back with was using the properties file to remove the user/pass from 'ps -ef' output.

If this doesn't meet the requirements of your security officer and/or the federal govt (I'm a state employee, so I feel the pain on that), then I recommend opening your own PMR with IBM on the subject.  An official response from an international, multi-billion-dollar-grossing corporation carries weight, even with the federal gov.  :)

Dan

Hi Danielle,

  Reading all the posts, and particularly last Dan post, my suggestion is
 
   1. Your properties file with user/password

   2. An script who read your properties file, write user/password(xor) temporally in soap.properties and call wsadmin without user/password

   3. When finish wsadmin, the script removes user/password from soap.properties and say goodbye with
   
   hope this helps.
   
regards,

Hmmmm....

Ok Dan.  That gets me closer to where I need to be but not quite.  I touched base with the security office and they basically told me I have to use AES 256 bit encryption for the passwords.   So, I'm thinking the PyCrypto module may be the best way to go....

Gabriel - I think I understand what you're saying.  I need to chew on it a little more to work out the process flow....

More to come!