Meet the experts: Keys Botzum on WebSphere security

This question and answer article features WebSphere consultant and security expert Keys Botzum who answers questions about WebSphere Application Server and WebSphere Portal security.

Keys Botzum, Senior Consultant I/T Specialist, IBM Software Services for WebSphere

Photo: Keys BotzumKeys Botzum is a Senior Consultant I/T Specialist with IBM Software Services for WebSphere (ISSW). He has over 10 years of experience in large scale distributed system design and additionally specializes in security. Keys has worked with a variety of distributed technologies, including Sun RPC, DCE, CORBA, AFS, and DFS. Recently, he has been focusing on J2EE and related technologies. You can find additional articles and presentations by Keys at and on IBM developerWorks WebSphere.

13 October 2004

Question: What are the best practices for updating passwords in WAS and WP? In our environment, we are forced to update every passwords every 90 days. In testing, we invariably have difficulties with WAS or WP. We need to change the WAS user's password, the DB2® user's password, any and every administration password. Luckily, we haven't yet deployed. In what order and where will we have to change passwords to prevent failure and maintain uptime? Is there a checklist somewhere or a script that would help us?

Answer: For WebSphere® Application Server (hereafter called Application Server), I recommend changing the Application Server registry password while Application Server is up, then changing it in Application Server, then restarting the cell one server at a time. This is important. If you change the registry password while Application Server is down, you will not be able to restart it.

For the database, the approach is similar. Change the password in the database, then in Application Server, and then restart. Here the order is less critical because Application Server does not validate the password when you change it.

In either case, there is a risk of an outage if a password happens to be used during the brief period of inconsistency. There is no way to avoid this, but if you have replicated servers and move fast, the risk should be minor.

For WebSphere Portal, there are additional passwords to consider. Fortunately, the WebSphere Portal support site includes a number of excellent documents describing how to change most of the passwords:

If you edit either password, you may also need to update the <WPS_ROOT>/config/ file. Note that the file is not used during the WebSphere Portal runtime. Be aware that I am not endorsing this. Storing passwords in the file is not a good idea. We recommend that you delete them at post install with:

WSPconfig cleanup-work-dir
WPSconfig delete-passwords

Question: Replacing the DummyKeys with keys from our internal CA proved difficult. We still have the issue that when a new node is installed and federated into the CELL, there are some manual changes required (1) before federation can begin, and (2) to ensure that the deployment manager can manage the new node agents. The root of the problem is due to the DefaultSSL repertoire, which points to the Dummy keys, and the SOAP JMX Administration port, which uses the DefaultSSL repertoire for its config. Is there are slick way to federate a node into a CELL without having to do manual configuration changes?

Answer: Unfortunately, this requires manual steps and there is no slick solution to do this. You need to install the new node standalone, copy the keys to the machine, change the node to use those new keys, and then federate the node into the cell. If the copied keys are placed properly after synchronization, the node should continue to use those keys. If you are concerned about reproducibility, it should be possible to create a wsadmin script that does the node SSL configuration and wraps the entire thing in a shell script that copies the keys, configures the node, and does the federation.

Question: I am an IT Architect and I am involved in a solution for designing a WPS shared environment. It means using one single WPS installation to be used for more than one company. Is it possible to setup this environment without security problems? Which security issues can you foresee?

Answer: There are numerous issues, which I can hardly begin enumerating:

  1. WebSphere Portal and WebSphere Application Server support only a single registry so how do you plan on managing users from multiple companies?
  2. How do you intend to manage the ACLs which control access to the portlets? You can delegate administration downward that will help, but I suspect this will get hard to manage.
  3. Do these companies need to deploy their own code to this common WebSphere Portal environment? If so, do you understand that WebSphere Portal and WebSphere Application Server do not provide application isolation? Thus, one application can harm the cell, and thus damage other unrelated applications.
  4. How do you intend to deal with application access? You want to ensure that different companies do not see each other's portlets.

Question: I wish to enable WAS global security to protect administration, but my application does not use J2EE security. Is there something I can do?

Answer: We strongly recommend that all WebSphere Application Server users enable global security. Failing to do so exposes the application server to numerous kinds of attacks because administrative actions are insecure. Usually, simply enabling global security works without any negative impact on applications. However, there is some measurable performance price and some APIs, such as request.getRemoteUser(), behave differently when security is enabled. If an application relies on request.getRemoteUser() to return the value of the Web CGI variable REMOTE_USER (which it should not since this is insecure when security is off), it breaks when security is on. The application server returns null unless the user has authenticated properly. If you are in this situation and are unable to change the application, in WebSphere Application Server 5.0 Network Deployment, when you enable global security, you can disable security on individual application servers. This is in the administrative console under server level security, Servers -> Application Servers -> <servername> -> Additional Properties -> Server Security -> Server Level Security.

This option does not exist unless the node is federated. By doing this, you have ensured that all internal administrative traffic is secured (encrypted and authorized), but at the same time you have disabled security on the applications running in the application server. Note that we strongly recommend that the application leverages J2EE security and to not disable security on the server level.

Question: What are things need to be considered while implementing a custom user registry in WebSphere Application Server?

Answer: Custom user registries (an implementation of the UserRegistry interface) make it possible for clients to use their own custom registries rather than the two that WebSphere Application Server supports natively: operating system and LDAP. First and foremost, we recommend against using a CUR if you can avoid it because this limits interoperability with other applications that use LDAP. However, if necessary, you can write a CUR. Be aware that your implementation of the custom registry may not depend on any WebSphere Application Server J2EE components, such as data sources, enterprise beans, and so on. This is because security is initialized and enabled prior to most of the other WebSphere Application Server components during startup. If your previous implementation (from WAS 4.0) used these components, make a change that eliminates the dependency. For example, if your previous implementation used data sources to connect to a database, use Java database connectivity (JDBC) to connect to the database. Note that with care (and a good understanding of the initialization process), it is possible to use a DataSource in a CUR, but only inside an application server (not a node agent), and only after the initialization is complete.

Question: Why is SWAM usage discouraged?

Answer: SWAM stands for Simple WebSphere Authentication Mechanism. The SWAM authentication mechanism is intended for simple, non-distributed, and single application server type runtime environments. The single application server restriction is due to the fact that SWAM does not support forwardable credentials. If a servlet or enterprise bean in application server process 1 invokes a remote method on an enterprise bean living in another application server process 2, the identity of the caller identity in process 1 is not transmitted to server process 2. What is transmitted is an unauthenticated credential, which, depending on the security permissions configured on the EJB methods, may cause authorization failures.

In addition, SWAM authentication state is maintained by using the HTTPSession rather than an independent cookie like LTPA. This weakens the security of the authentication because HTTPSessions are not designed to be secure. For example, bad LTPA tokens are audited.

You can use SWAM as an authentication mechanism in WebSphere Application Server (base) v5.0. SWAM is not a supported option for WebSphere Application Server Network Deployment v5.0, and even in base, its use is discouraged.

Question: Why do I need to enable SSO when using Form-based Login in my WebSphere Application Server application?

Answer: The reason is very simple. By enabling SSO, WebSphere Application Server maintains user state as an LTPA cookie across Web requests. If SSO is not enabled, each individual request requires authentication. If you choose to use form based login, once the form completes authenticating the user, it then redirects back to the originally requested URL. Without SSO, the user's authentication is now lost and those authorization will fail. This is not seen when using basic authentication because the authentication information is in every HTTP request and WebSphere Application Server can use it whenever needed (this does impact both security and performance).

Question: I want to force my users to re-login after a set "inactivity timeout" period. How is WAS supposed to work with regard to session timeouts and LTPA timeouts?

Answer: The WebSphere Application Server LTPA token expires based on the lifetime of the login session, not based upon inactivity. Thus, the WebSphere Application Server login session will not expire if the user performs no action for some period of time. However, the HTTPSession does expire based upon inactivity.  If in your application you need to expire the use of an application based on idleness, you have to explicitly code this in your application. You can capture when a user arrives with an expired session (really a new session) and force them to login again if you think this is necessary. Keep in mind that doing this undermines Single Sign On across applications.

Question: I am struggling with a problem in binding my objects to WebSphere Application Server's naming directory. I have been talking to IBM support on this for the past one week without much luck except tons of Redbook links from him. I am connecting to port 2809 on WAS 5.x server and getting no permission exception. User name and passwords are what I use to login to administrative console and they are part of the LDAP I am using. If you can even point me to a sample program or something related, that would be a great help.

WebSphere (for both network and base product)
Problem Statement:
We get a CORBA_NO_EXCEPTION error when we try to connect to a naming service running under "Global Security" turned on.
Naming Environment Settings:
ALL_AUTHENTICATED Cos Naming Read, Cos Naming Write, Cos Naming Create, Cos Naming Delete. EVERYONE Cos Naming Read

Steps to the problem:

  1. Turn on the "Global Security" in the Administration console and turn off "Enforce Java 2 Security".
  2. Active user registry is set to "Local OS" / "LDAP" and Active protocol is "CSI and SAS".
  3. Restart Deployment manager, nodeagent and application nodes with new "root" username and password.
  4. Run a program (invoked through a servlet) that connects to local naming service at port 2809.
  5. Exception is thrown on namingcontext.rebind() call.

Program generating the error:

try{env.put(InitialContext.PROVIDER_URL, "iiop://");
// Greg: for the authentication type we have tried "simple" , "strong" and "LTPA" without any luck.
env.put(javax.naming.Context.SECURITY_AUTHENTICATION, "simple");
env.put(javax.naming.Context.SECURITY_PRINCIPAL, "root");
env.put(javax.naming.Context.SECURITY_CREDENTIALS, "rootpassword");
ctxt = new javax.naming.InitialContext(env);
ctxt.rebind("aName", obj);
}catch(Exception e){

Exception printed by aforementioned printStackTrace is following:
<<< Exception from SystemOut.log
[9/22/04 15:40:41:895 PDT] 7dc141 Helpers W NMSV0610I: A NamingException is being thrown from 
a javax.naming.Context implementation. Details follow:
Context implementation:
Context method: rebind
Context name: DEVNetwork/nodes/DEV/servers/nodeagent
Target name: server2-2809-NotificationImpl
Other data: Object to bind:
Exception stack trace: javax.naming.NoPermissionException: NO_PERMISSION exception caught. 
Root exception is org.omg.CORBA.NO_PERMISSION: 
Trace from server: 298002686 at host >>
org.omg.CORBA.NO_PERMISSION: not authorized to perform rebind_corba_object operation. 
minor code: 0 completed: No
at Source)
<< END server: 298002686 at host
minor code: 0 completed: No
at java.lang.reflect.Constructor.newInstance(Native Method)
at org.omg.CORBA.portable.ObjectImpl._invoke(
at Source)
at javax.naming.InitialContext.rebind(
at javax.naming.InitialContext.rebind(

Answer: You are assuming WebSphere Application Server is using authentication data that is specified in the InitialContext creation to authenticate. This is not the case. WebSphere Application Server security is based on a robust model where security context information is carried on the current thread and sent over IIOP when performing remote calls. To access JNDI as an authenticated user, you must authenticate to WebSphere Application Server in your code prior to creating the InitialContext. It is not clear from your example, but I will assume you are using a Java™ client. You need to authenticate to WebSphere Application Server using JAAS authentication as provided in the LoginContext. Refer to WebSphere Application Server Information Center, Configuring Java Authentication and Authorization Service login section.

Question: We are trying to do Client Certificate Authentication, but with no output until now. We have configured User registry to the Local OS. I went through the WebSphere security document, which I got from the IBM Redbooks site, but it talks about LDAP settings and not the Local OS. Can you provide step by step instructions?

Answer: You have not provided sufficient details for me to be certain I understand what you are asking. I can say the following:

  1. Client certificates are not supported when using the Local OS registry for Web based authentication. Refer to WebSphere Application Server Information Center, Local operating system user registries section. Here is an excerpt: "Web client certificate authentication is not currently supported when using the local operating system user registry. However, Java client certificate authentication does function with a local operating user registry. Java client certificate authentication maps the first attribute of the certificate domain name to the user ID in the user registry."
  2. As the documentation implies, there are no configurable registry features related to certificate authentication when using the LocalOS registry. With LDAP (or custom), there is far more flexibility.

If you wish to use client certificate authentication, I recommend that you not use the Local OS registry.

Question: We use MQ WorkFlow v3.5 under W2K and Web. We want to access to the staff/Person properties using the Workflow API, and/or to start a process instance, but without logon(). This way we do not need to code a User and a Password in the JSP.

Answer: Your question is very unclear and is not related to WebSphere Application Server, but here is an answer that might be related to your question. I think that what you want to do is to set up a starter user. This allows a non-Workflow user to initiate a Workflow process without explicitly logging on to Workflow (but the user cannot have any work items assigned to him or her). This is used in the WebCredit example (SupportPac WA82).

  1. Edit the /WebClient/WEB-INF/ file.
  2. Specify the StarterUserID, StarterPassword, StarterSystemGroup, and StarterSystem.
  3. Re-start the Web Client.

Ensure that there is no staffing API in the Workflow.

Question: (Solaris WAS 5.1.05 Network Deployer Custom User Registry) I follow the installation steps to the "t" and still get "No Group was found in User Registry Repository" with this name, Do I need to compile this file?

# users.props
# Format:
# name:passwd:uid:gids:display name
# where name   = userId/userName of the user
#       passwd = password of the user
#       uid    = uniqueId of the user
#       gid    = groupIds of the groups that the user belongs to
#       display name = a (optional) display name for the user.


# groups.props
# Format:
# name:gid:users:display name
# where name   = groupId of the group
#       gid    = uniqueId of the group
#       users  = list of all the userIds that the group contains
#       display name = a (optional) display name for the group.


Answer: No, the user file does not need to be compiled. The FileRegistry has been used successfully by many customers, so there is likely some type of configuration problem. Without any additional detail, I cannot provide an answer. I suggest you collect the WebSphere Application Server tracing and contact IBM support.


The author wants to thank the following ISSW consultants for their help in preparing this article:

  • Saravana R. Chandran
  • Harold L. Creel
  • Paul Ilechko
  • Bruce Nuechterlein
  • Irina Singh
  • John Wang


About Meet the experts

Meet the experts is a monthly feature on the developerWorks WebSphere Web site. We give you access to the best minds in IBM WebSphere, product experts and executives, who are waiting to answer your questions. You submit the questions, and we post answers to the most popular questions.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Meet the experts: Keys Botzum on WebSphere security