Q & A: Frequently asked questions about

WebSphere Application Server security

Skill Level: Intermediate

Keys Botzum
Senior Technical Staff Member
IBM

Bill O'Donnell
Lead WebSphere Security Architect
IBM

03 Mar 2010

Updated 09 Aug 2011

Because the integrity of your processing environment is at stake, questions about

security must be answered as quickly as possible. To that end, this article provides
quick, direct answers to some of the most frequently asked questions about IBM®
WebSphere® Application Server security.

Important FAQs
A subject area as critical as application server security prompts a noteworthy volume
of equally critical questions. To help you better understand IBM® WebSphere®
Application Server security in general, and how it is (or should be) applied in your
environment, here are some of the most frequently asked questions, as they apply to
WebSphere Application Server V6.1 and later (unless otherwise noted).

The questions and answers listed here are presented in three broad categories:

Registry

1. When does WebSphere Application Server contact the registry for user

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 1 of 14
developerWorks® ibm.com/developerWorks

information?

2. Does WebSphere Application Server work with NIS?

3. What are my options if I want to turn on security with a non-administrator

account in a Windows® environment?

4. What are my options if I want to turn on security with a non-root server ID

in a UNIX® environment?

5. Will Local OS authentication work in a distributed environment?

6. My users authenticate with one userid but I want them to be identified with
another ID from LDAP. Is that possible?

7. When using a federated repository, is there a way to ensure that my

file-based registry will continue to function when a LDAP server is down?

Authentication

8. Why do I need to enable SSO when using form-based login in my

WebSphere Application Server application?

9. I want to force my users to login again after a set "inactivity timeout"

period. How is WebSphere Application Server supposed to work with
regard to session timeouts and LTPA timeouts?

10. Is there anything I can do to prevent my LTPA keys from becoming out of
sync between my cells?

11. Can a WebSphere Application Server cell span multiple DNS domains?

12. Why is SWAM usage discouraged?

13. When should I use a custom login module versus a TAI to assert identity
information?

Other security questions

14. How do I change my passwords (database, LDAP, and so on) without

causing an outage?

15. What WebSphere Application Server proprietary extensions provide for

J2EE™ security?

16. Does WebSphere Application Server support CA Siteminder?

Frequently asked questions about WebSphere Application Server security

Page 2 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.
ibm.com/developerWorks developerWorks®

17. WebSphere Application Server stores passwords XOR encoded. I'd like to
use something stronger. What can I do?

18. How can I debug the Java™ 2 security exceptions and

AccessControlExceptions?

19. Is there any documentation available on how best to configure Microsoft

Active Directory with WebSphere Application Server?

Registry
1. When does WebSphere Application Server contact the registry for user
information?

WebSphere Application Server queries the registry for user information as well as for
administrative operations. Thus, the registry must be nearly 100% available for a
WebSphere Application Server cell to function.

Here are the reasons why WebSphere Application Server will contact the registry:

• When users authenticate (password or certificate, and not needed with

a Web SSO proxy). WebSphere Application Server might query when it:
• Checks the user's password.
• Maps certificate information to a userid.
• Converts userid to registry uniqueid (for example, LDAP DN).
• Obtains group information.
• When an LTPA token is passed to a server for the first time.
WebSphere Application Server still obtains group information even when
a Lightweight Third Party Authentication (LTPA) token is passed to a
server for the first time (for example, by WebSEAL or IIOP traffic)
because the LTPA token contains only the user's distinguished name
(DN). The same applies for Trust Association Interceptors (TAIs) because
they normally provide only the userid. If WebSphere Application Server
V5.1.1 is used, AND subject propagation is enabled, AND the TAI or login
module projects group information (as the new WebSEAL TAI in
WebSphere Application Server V5.1.1 can do), then WebSphere
Application Server will not query LDAP for user group information for that
user.
• If the subject propagation fails. Even with subject propagation enabled,
if the subject propagation were to fail (for example, if a server is down),

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 3 of 14
developerWorks® ibm.com/developerWorks

then WebSphere Application Server will attempt to recreate the subject

unless a custom cache key has been set.
• When users authenticate for administrative operations (Web, JMX,
and so on).
• Whenever an application starts, the role bindings are verified against
the registry
• Whenever an administrator sets binding information in the
administrative console.
2. Does WebSphere Application Server work with NIS?

WebSphere Application Server does not directly support NIS (Network Information
Service) for authentication. It supports LDAP, OS, and custom. When running on a
UNIX operating system, WebSphere Application Server uses the standard UNIX
password APIs (getpw*, and so on) for verifying user password (WebSphere
Application Server must run as root for this to work). If those APIs call to NIS, then
WebSphere Application Server will use NIS for authentication, but this is transparent
to WebSphere Application Server. However, when an OS registry is used on UNIX,
then multi-node cells are not supported.

It might be possible to write a custom registry to use NIS.

In most cases, the answer to this question is no.

3. What are my options if I want to turn on security with a non-administrator

account in a Windows environment?

When running the WebSphere Application Server processes as a non-administrator,

if global security is enabled, the user registry must be either LDAP or a custom
registry

To use the Local OS user registry, the user under which the product processes run
must have Administrative and Act as part of the operating system privileges to
call the Windows operating system APIs that authenticate or collect user and group
information. The process needs special authority, which is given by these privileges.
The user in this example should not be the same as the security server ID (the
requirement for which is a valid user in the registry). This user logs into the machine
(if using the command line to start the product process) or the Log On User setting in
the services panel (if the product processes have started using the services). If the
machine is also part of a domain, this user should be part of the Domain Admin
group in the domain to call the operating system APIs in the domain, in addition to
having the Act as part of operating system privilege in the local machine.

4. What are my options if I want to turn on security with a non-root server ID in

a UNIX environment?

Frequently asked questions about WebSphere Application Server security

Page 4 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.
ibm.com/developerWorks developerWorks®

When running WebSphere Application Server as non-root, if global security is

enabled, the user registry must be either LDAP or a custom registry.

To use the Local OS user registry, the user under which the product processes run
must have the root privilege. This privilege is needed to call the UNIX operating
system APIs to authenticate or to collect user and group information. The process
needs special authority, which is given by the root privilege. Using the Local OS user
registry requires the node agent, the deployment manager, and the application
server process to run as root.

5. Will Local OS authentication work in a distributed environment?

In WebSphere Application Server Network Deployment with application server

nodes distributed over more than one physical machine, you cannot use Local OS
authentication. In this environment, you must use either LDAP or a custom registry.
There is one exception though; a Windows domain registry is a centralized registry
and can be used in this situation. Be aware that NIS, while technically a centralized
registry, is not suitable for use with WebSphere Application Server Network
Deployment.

More information can be found in the Information Center article: Local operating
system registries.

6. My users authenticate with one userid but I want them to be identified with
another ID from LDAP. Is that possible?

There is a way to configure WebSphere Application Server to do just that. This

assumes that the LDAP entry for each user has an attribute containing a string that
can be used for the second userid. For example, let's call this attribute myname.
Let's also assume the userid used for authentication is contained in an LDAP
attribute called uid.

In the WebSphere Application Server LDAP configuration (from the administrative

console, click Security > User Registries > LDAP > Advanced LDAP Settings),
modify the User ID map field from *:uid to *:myname . This basically tells
WebSphere Application Server to set the J2EE principal that is returned to the
application to the value of the myname LDAP attribute. Normally, WebSphere
Application Server would return the same userid that was used to logon.

As an example, assume that a user's LDAP entry has the following attribute/value
pairs: uid=dale.sue.ping, myname=sueping.

With the above WebSphere Application Server LDAP configuration change, the user
would logon with a userid of dale.sue.ping, authenticate with WebSphere
Application Server/LDAP and, on a successful authentication, WebSphere
Application Server will set the J2EE principal to sueping.

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 5 of 14
developerWorks® ibm.com/developerWorks

If the application has the capability to extract the J2EE principal, the application will
see the user as "sueping" and not as "dale.sue.ping."

7. When using a federated repository, is there a way to ensure that my

file-based registry will continue to function when a LDAP server is down?

Yes, there is a configuration option that enables the authentication to continue if one
or more other registries are down, as long as the ID is found in one of the registries
that are still up and functional. The federated repository configuration command to
permit this is:

$AdminTask createIdMgrRealm -name ibmRealm

-allowOperationIfReposDown true

More information can be found in the Information Center article: IdMgrRealmConfig

command group for the AdminTask object.

Authentication
8. Why do I need to enable SSO when using form-based login in my
WebSphere Application Server application?

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 then redirects back to the originally requested URL. Without
SSO, the user's authentication is now lost and the 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).

9. I want to force my users to login again after a set "inactivity timeout" period.
How is WebSphere Application Server supposed to work with regard to
session timeouts and LTPA timeouts?

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 must 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.

Frequently asked questions about WebSphere Application Server security

Page 6 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.
ibm.com/developerWorks developerWorks®

A second approach that is a slight variation on the first is to use

HTTPSession.getLastAccessTime() to compute when the last client request
occurred. If the time is too far into the past, you can of course fail the access and
force a new authentication.

Either of these approaches can be made transparent to the application code through
the use of servlet filters.

It should be noted that IBM Tivoli® Access Manager provides for lifetime- and
idle-based authentication session timeouts.

Users often ask why WebSphere Application Server works this way. Why can't it
timeout idle login sessions? The reason is because WebSphere Application Server
is fundamentally a loosely coupled distributed system. Application servers that
participate in an SSO domain don't need to talk to each other. They don't even have
to be in the same cell. So, if you want to limit the idleness lifetime of an LTPA token
(aka SSO token), you'd have to update the token itself with a last usage time on
every request (or perhaps on the first request seen during a one minute interval).
This means that the token itself would change frequently (meaning the browser
would be accepting new cookies frequently) and that WebSphere Application Server
would have to decrypt and verify the inbound token when it is seen to validate it.
That could be expensive (WebSphere Application Server today only validates a
token on the first use at each application server). It's not impossible to solve these
problems with clever caching and such, but that's not how WebSphere Application
Server works today.

10. Is there anything I can do to prevent my LTPA keys from becoming out of
sync between my cells?

Yes. WebSphere Application Server V6.1 introduced a feature that enabled by

default to automatically regenerate your LTPA keys. While this is a real nice feature
for a simple cell configuration, any user who has multiple cells and requires that
LTPA keys be in sync between the cells should turn off the auto-regen feature for
LTPA. In WebSphere Application Server V7, this feature is off by default, and in for
any new profiles that are created V6.1.0.23 this feature is turned off by default.

11. Can a WebSphere Application Server cell span multiple DNS domains?

Prior to WebSphere Application Server V6, the answer was no. This is because
when you configured WebSphere Application Server security, one of the items you
needed to specify was the LTPA token SSO domain. If you left it blank, the LTPA
token/cookie domain was set to blank, which meant that the cookie went back to the
same host only. If you provided a value, the cookie domain was set to that and then
the cookie would go back to hosts within the same DNS domain. This is the behavior
required by the HTTP specification. The problem was that if your cell (or really the
Web servers) served requests for multiple DNS domains, there was no way to

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 7 of 14
developerWorks® ibm.com/developerWorks

specify more than one domain. As of WebSphere Application Server V6, the SSO
domain value specified to WebSphere Application Server can contain multiple DNS
domains. Now, you specify all of the domains you need. When WebSphere
Application Server creates the cookie, it will set the domain value for the cookie (the
HTTP spec allows for only one value) to the value from the inbound request that
matches one of the configured domains.

Examples of a valid domain name are ibm.com and tx.gov. Examples of invalid
domain names are ibmus and state_tx.gov. Some users have experienced a
problem with Internet Explorer (IE), in that IE 5 and IE 6 do not seem to accept the
LTPA token when the domain defined in the SSO domain field is less than five
characters, excluding the period, such as "cn.ca". Microsoft has a fix for this.

12. Why is SWAM usage discouraged?

The Simple WebSphere Authentication Mechanism (SWAM) is intended for simple,

non-distributed, single application server run time environments. The single
application server restriction is due to the fact that SWAM does not support
forwardable credentials. What this means is that if a servlet or enterprise bean in
one application server process invokes a remote method on an enterprise bean
living in another application server process, the caller identity is not transmitted to
the second server process. What is transmitted is an unauthenticated credential,
which, depending on the security permissions configured on the EJB methods, might
cause authorization failures.

SWAM can be used as an authentication mechanism in the base edition of

WebSphere Application Server. SWAM is not a supported option for WebSphere
Application Server Network Deployment V5.0. Using it in the base edition is even
discouraged because it relies on the HTTP Session object for maintaining the user
state, which is problematic since the HTTP Session layer is not part of the security
infrastructure.

13. When should I use a custom login module versus a TAI to assert identity
information?

Note: If a user has already been authenticated by some authentication system other
than WebSphere Application Server, it is possible to inform WebSphere Application
Server of the user's identity information rather than requiring that the user
re-authenticate. This is known as identity assertion. For more information about
identity assertion as it relates to TAI, see Advanced authentication in WebSphere
Application Server.

Table 1. Login module vs. TAI

Feature Login module TAI
IBM proprietary No, but requires WebSphere Yes
Application Server specific code
anyway

Frequently asked questions about WebSphere Application Server security

Page 8 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.
ibm.com/developerWorks developerWorks®

Ease of use Harder Easier

Multi-phase authentication No Yes
Suppress Web login challenge No Yes
Can be used for Web calls Yes Yes
Can be used for RMI calls Yes No
(Re)called for propagation Yes No
logins

Other security questions

14. How do I change my passwords (database, LDAP, and so on) without
causing an outage?

a. Alternate using a pair of userids, such as useridA and useridB, and

assume you are currently running using useridA.

b. Set the new password for useridB.

c. Change every use/occurrence of useridA to useridB with the new

password. It helps to keep good documentation here.

d. Recycle each server in the cluster in turn, so that you always have a node
running.

e. Set the new password for useridA. If you missed something in step 3, it
will break but it will not affect the other correctly changed occurrences.

f. The next time you change passwords, switch from useridB back to
useridA.

As both userid/password combinations are valid during the transition, you don't have
to worry about synchronization.

15. What WebSphere Application Server proprietary extensions provide for

J2EE security?

• LTPA token is non-standard, but is simply a credential/token and does

not impact the application development team.
• Redirects to the ibm_security_logout URL in order to remove the LTPA
token when users log out.
• WSSubject, WSCredential, and WSPrincipal are IBM extensions to the

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 9 of 14
developerWorks® ibm.com/developerWorks

standard J2EE Subject, Credential, and Principal classes. They are

needed in some cases due to shortcomings in the standard classes.
• Trust Association Interceptors (TAI) are often used for WebSphere
Application Server interface with SSO proxies (WebSEAL, ClearTrust,
Siteminder, and so on). Again, this is just the authentication layer and
should not affect application portability, other than if you do move to
another J2EE container you must ensure that a similar interface is
provided between the SSO proxy and WebSphere Application Server. Be
aware if your developers are using SSO proxy-specific APIs.
• Custom User Registry (CUR) is also just an integration layer for users
who are not using one of the standard WebSphere Application Server
registry types (Operating System, LDAP) or are using them in
non-standard ways.
• Java 2 Security Policy Files contain a few minor extensions to the
standard. Again, they are infrastructure and not part of your application
code, but the was.policy file is included in the EAR file.
• WebSphere Application Server Administrative APIs are WebSphere
Application Server administrative facilities that are available in API form
so that they can be called from applications. While some of this can be
done using the JMX standard, other APIs are WebSphere Application
Server-specific. It is unlikely (and should be forbidden) that these will be
used in business applications, but keep these in mind in case you are
writing administrative applications.
• wsadmin scripting is technically not part of your business applications
either, but keep in mind that scripts written for admin functions must be
rewritten if you port to another product. For tasks like deployment, it is
best to use something like Ant, which is an open standard. Be aware that
some Ant commands that come with WebSphere Application Server, IBM
WebSphere Studio Application Developer, and IBM Rational® Application
Developer are IBM specific.
Also, keep in mind that there are other proprietary APIs available that are not part of
security, such as the dynacache APIs for commands, and Java object caching and
WebSphereMQ calls that are outside of JMS.

16. Does WebSphere Application Server support CA Siteminder?

WebSphere Application Server provides a security authentication plug point known

as a Trust Association Interceptor (TAI), which delegates authentication to a vendor
(non-WebSphere Application Server) security provider. Examples of common
products that are employed as such include IBM Tivoli Access Manager, CA
Siteminder, and RSA Clear Trust. All of these products are responsible for their own
implementation that leverages the WebSphere Application Server TAI plug point,

Frequently asked questions about WebSphere Application Server security

Page 10 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.
ibm.com/developerWorks developerWorks®

and for insuring that it functions with their solution.

For example, Siteminder develops and sells a TAI for WebSphere Application
Server. CA is responsible for support of Siteminder and the TAI they design and
develop for the integration of Siteminder with WebSphere Application Server. From a
WebSphere Application Server perspective, you can use any of these products you
wish, but any questions or problems you experience must be handled through the
vendor, such as CA for Siteminder. As they do with IBM, users pay CA for the
license to use and receive support for Siteminder. IBM does not have the means or
the responsibility to fix Siteminder, the Siteminder TAI, or any Siteminder
accessories.

In addition to the Trust Association Interceptor, WebSphere Application Server offers

additional plug points that you can leverage, such as the Custom User Registry,
JAAS, and JACC. It is important to understand that the support line is at the plug
point. By design, WebSphere Application Server will support up to the plug point,
and the implementer (such as Siteminder) is responsible for the implementation of
the plug point, which is designed to work with their solution.

17. WebSphere Application Server stores passwords XOR encoded. I'd like to
use something stronger. What can I do?

Prior to WebSphere Application Server V6.0.2, there was little you could do in
general. If you didn't like how WebSphere Application Server stored passwords for
the J2C resources, you could write you own custom J2C login module to get
passwords from a source outside of WebSphere Application Server, but this wouldn't
help with other passwords used by WebSphere Application Server: LDAP bind,
WebSphere Application Server admin, and so on.

With WebSphere Application Server V6.0.2, you can actually configure your own
custom password encoder that can implement whatever protection you deem
appropriate. To do this you implement the plugin interface
(com.ibm.wsspi.security.crypto.CustomPasswordEncryption) and then specify two
custom security properties in security.xml. You can also set these in
PropFilePasswordEncoder.bat/sh. The two properties are:

• com.ibm.wsspi.security.crypto.customPasswordEncryptionClass
• com.ibm.wsspi.security.crypto.customPasswordEncryptionEnabled.
For more information, see the Information Center article: Plug point for custom
password encryption.

18. How can I debug the Java 2 security exceptions and

AccessControlExceptions?

There are two primary aids, the WebSphere SystemOut.log file and the

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 11 of 14
developerWorks® ibm.com/developerWorks

com.ibm.websphere.java2secman.norethrow property.The AccessControlException

logged in the SystemOut.log file contains the permission violation that causes the
exception, the exception call stack, and the permissions granted to each stack
frame. This information is usually enough to determine the missing permission and
the code requiring the permission.

When Java 2 security is enabled in WebSphere Application Server, the security

manager component throws a java.security.AccessControl exception when a
permission violation occurs. This exception, if not handled, often causes a run time
failure. This exception is also logged in the SystemOut.log file.

However, when the JVM com.ibm.websphere.java2secman.norethrow property is

set and has a value of true, the security manager does not throw the AccessControl
exception. This information is logged.

To set the com.ibm.websphere.java2secman.norethrow property for the server, go to

the WebSphere Application Server administrative console and select Servers >
Application Servers. Under Additional Properties, click Process Definition > Java
Virtual Machine > Custom Properties > New. In the Name field, type
com.ibm.websphere.java2secman.norethrow. In the Value field, type true.

19. Is there any documentation available on how best to configure Microsoft

Active Directory with WebSphere Application Server?

Yes, we recently added some helpful tips based on experience our IBM Software
Services for WebSphere team has had with other customers. Please refer to our
Using Microsoft Active Directory with IBM WebSphere Application Server white
paper.

Summary
If your most important security questions were not answered here, be sure to check
the Resources below, and particularly the new WebSphere Application Server
security resources page on developerWorks, where much of the most noteworthy
material on WebSphere Application Server security will be continually spotlighted.

Frequently asked questions about WebSphere Application Server security

Page 12 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.
ibm.com/developerWorks developerWorks®

Resources
• WebSphere Application Server security resources
• Advanced authentication in WebSphere Application Server
• Using Microsoft Active Directory with IBM WebSphere Application Server
• Information Center
• All WebSphere Application Server Information Centers
• Local operating system registries
• IdMgrRealmConfig command group for the AdminTask object
• Plug point for custom password encryption
• Internet Explorer does not set a cookie for two-letter domains

• IBM developerWorks WebSphere Application Server zone

• IBM developerWorks WebSphere

About the authors

Keys Botzum
Keys Botzum is a Senior Technical Staff Member with IBM Software Services for
WebSphere. Mr. Botzum has over 10 years of experience in large scale distributed
system design and additionally specializes in security. Mr. Botzum 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. He holds a
Masters degree in Computer Science from Stanford University and a B.S. in Applied
Mathematics/Computer Science from Carnegie Mellon University. Mr. Botzum has
published numerous papers on WebSphere and WebSphere security. Additional
articles and presentations by Keys Botzum can be found at
http://www.keysbotzum.com, as well as on IBM developerWorks WebSphere. He is
also co-author of IBM WebSphere: Deployment and Advanced Configuration.

Bill O'Donnell
Bill O'Donnell is the Lead WebSphere Security Architect working in the WebSphere
product development organization. He is responsible for the security architecture for
WebSphere Application Server. Bill has has over 25 years experience in large scale

Frequently asked questions about WebSphere Application Server security

© Copyright IBM Corporation 2010, 2011. All rights reserved. Page 13 of 14
developerWorks® ibm.com/developerWorks

mainframe and distributed system with a unique focus on development architecture

and infrastructure architecture. Bill specializes in end to end infrastructure and
application security. He has published a number of Redbooks and is the author of the
Secrets of SOA. Bill is a co-sponsor of the WebSphere Application Server security
web site.

Frequently asked questions about WebSphere Application Server security

Page 14 of 14 © Copyright IBM Corporation 2010, 2011. All rights reserved.