Q & A: Frequently asked questions about WebSphere Application Server security

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. This content is part of the IBM WebSphere Developer Technical Journal.

Keys Botzum, Senior Technical Staff Member , IBM

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.


developerWorks Professional author
        level

Bill O'Donnell, Lead WebSphere Security Architect, IBM

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



May 2014 (First published 03 March 2010)

Also available in Chinese Russian Japanese Spanish

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

  1. Why do I need to enable SSO when using form-based login in my WebSphere Application Server application?
  2. 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?
  3. Is there anything I can do to prevent my LTPA keys from becoming out of sync between my cells?
  4. Can a WebSphere Application Server cell span multiple DNS domains?
  5. Why is SWAM usage discouraged?
  6. When should I use a custom login module versus a TAI to assert identity information?

Other security questions

  1. How do I change my passwords (database, LDAP, and so on) without causing an outage?
  2. What WebSphere Application Server proprietary extensions provide for J2EE™ security?
  3. Does WebSphere Application Server support CA Siteminder?
  4. WebSphere Application Server stores passwords XOR encoded. I'd like to use something stronger. What can I do?
  5. How can I debug the Java™ 2 security exceptions and AccessControlExceptions?
  6. Is there any documentation available on how best to configure Microsoft Active Directory with WebSphere Application Server?
  7. How can I programmatically get a password from a J2C alias configuration?
  8. Does WebSphere Application Server support Microsoft NTLM?
  9. What provisions does WebSphere Application Server provide to prevent denial of service attacks?
  10. How do I configure WebSphere Application Server with firewalls or to use a management network?

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), 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?

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.

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 updateIdMgrRealm -name <byRealmName> -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.

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 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
FeatureLogin moduleTAI
IBM proprietaryNo, but requires WebSphere Application Server specific code anywayYes
Ease of useHarderEasier
Multi-phase authenticationNoYes
Suppress Web login challengeNoYes
Can be used for Web callsYesYes
Can be used for RMI calls YesNo
(Re)called for propagation loginsYesNo

Other security questions

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

  1. Alternate using a pair of userids, such as useridA and useridB, and assume you are currently running using useridA.
  2. Set the new password for useridB.
  3. Change every use/occurrence of useridA to useridB with the new password. It helps to keep good documentation here.
  4. Recycle each server in the cluster in turn, so that you always have a node running.
  5. 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.
  6. 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 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, 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 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.

20. How can I programmatically get a password from a J2C alias configuration?

The sample below can be used to programmatically get the userid and password from a J2C alias in the WebSphere Application Server configuration. The DefaultPrincipalMapping LoginContext needs two arguments

  • A WSMappingCallbackHandler containing (indirectly) the alias that you want the password for.
  • A Subject which will be modified via the LoginModules login() method(s) in the Login configuration.

The WSMappingCallbackHandler obtains the alias' password from the WebSphere Application Server security configuration, and the Login modules copy it into a PasswordCredential in the Subject.

Listing 1. Getting a password from the J2C Alias in the WebSphere Application Server configuration
//* Imports needed for this sample
import javax.security.auth.callback.CallbackHandler;
import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory;
import javax.security.auth.Subject;
javax.security.auth.login.LoginContext;

//* Coding example — try/catch blocks have been omitted
Map map = new HashMap();
map.put(Constants.MAPPING_ALIAS, alias);
//create a callback handler with the specified property (to find the alias)
//and null for the managed connection factory (MCF) since we don't need it
CallbackHandler handler = WSMappingCallbackHandlerFactory
				.getInstance().getCallbackHandler(map, null);
Subject subject = new Subject();
LoginContext lc = new LoginContext("DefaultPrincipalMapping", subject, handler);
lc.login();
subject = lc.getSubject();

Set pwdCredentialSet = subject.getPrivateCredentials(PasswordCredential.class);

PasswordCredential cred = (PasswordCredential)  pwdCredentialSet.iterator().next();
String password = null;
String userid = null;
if (cred != null) {
		password = new String(cred.getPassword());
		userid = cred.getUserName();
} else {
		out.println("No password credential");
}

21. Does WebSphere Application Server support Microsoft NTLM?

WebSphere Application Server and other IBM products that run on a WebSphere Application Server, such as WebSphere Portal, do not currently support NTLM (NT LAN Manger). Both IBM and Microsoft "do support" basic authentication, Mutual Authentication, and the use of SAML or Kerberos in some form, depending on the application protocol being used.

Further, WebSphere Application Server has no plans for supporting NTLM, given the technical challenges and limitations around developing a complete solution using NTLM. In brief, NTLM is a Microsoft closed HTTP transport security protocol that provides authentication, integrity, and confidentiality for web applications running on the Microsoft platform, designed to only work within a Microsoft networking environment. Microsoft has also published a statement that it no longer recommends using NTLM.

Microsoft does offer other standards-based HTTP transport options as alternatives to NTLM, such as Basic Authentication, Mutual Authentication, Kerberos, and SAML, all of which provide for multiple platform interoperability and are supported by WebSphere Application Server.

For web services applications using the WS-Security standards, both Microsoft .NET and WebSphere Application Server applications can use the above HTTP transport authentication. They can also support the SOAP message authentication based on WS-Security standards, such as UsernameToken, Kerberos tokens, SAML token, and authentication based on X509. In addition, both Kerberos and SAML support the ability to flow either a server identity or a client identity to a SOAP-based web service provider. It is also worth noting that the WS-Security OASIS standards body, of which both Microsoft and IBM are voting members, endorses the use of SAML Web Services Token Profile for WS-Security based applications.

In regard to NTLM, there are technical challenge and limitations around developing solutions using NTLM:

  • NTLM is a proprietary protocol that works automatically for Windows domain user and system accounts within a Microsoft Active Directory environment.
  • There are a number of open source libraries where, given a user, a domain name or NETBIOS name and the password for the user, it can generate an NTLM token. The Java 6 runtime, on which WebSphere Application Server runs, can generate an NTLM if provided with these three parameters. Again, these libraries are meaningful in environments where the process has access to a password for an account, or where the process is running on a Windows machine with a Windows AD domain identity.
  • In an application server, threads execute on behalf of multiple users, and the passwords for those users are not available or not stored. In the absence of an end user password, by definition, there exists no mechanism to generate an NTLM for that end user. While it is possible to provide a library a single userid and password, this only allows for the generation of an NTLM authentication for the server Identity. Use cases that require the client identity to flow as part of the service call cannot be supported by NTLM on application servers.

Be aware that Microsoft's recommended replacement authentication technology, Kerberos, supports credential delegation which enables the propagation of user identity through applications without requiring the user password. Similarly, SAML-based authentication supports propagation of user identity without a password, or an original Kerberos identity.

22. What provisions does WebSphere Application Server provide to prevent denial of service attacks?

Prevention and mitigation of denial of service (DOS) attacks is best accomplished using firewalls and network configuration, not with WebSphere Application Server (or any middleware for that matter). This is because relying on WebSphere Application Server for DOS protection means that DOS attack traffic has already impacted your network, so any remedy that WebSphere Application Server can provide will have limited effectiveness.

That said, there are some configuration options that can be employed to reduce the impact of a DOS attack to WebSphere Application Server request processing, starting with the WebSphere Application Server HTTP server plugin. These properties in the HTTP server plugin configuration file (plugin-cfg.xml) can be set to limit the impact of large or long running requests and prevent retrying these requests, which could be associated with a DOS attack:

  • MaxConnections
  • ServerIOTimeOut
  • PostSizeLimit
  • PostBufferSize
  • ServerIOTimeoutRetry

The number of requests on a keep-alive (persistent) connection and the number of client connections on the the web container transport can be limited by setting:

  • Persistent Connections/Request
  • Maximum Open Connections

as well as these HTTP request web container attributes, which can limit request size:

  • Maximum header field size
  • Maximum headers
  • Limit request body buffer size
  • Maximum request body buffer size

Again, with regard to limiting the HTTP data size, this is best done by the firewall or web server, not by WebSphere Application Server.

23. How do I configure WebSphere Application Server with firewalls or to use a management network?

First, before discussing your network options for using firewalls or a management network, it's essential to understand that a WebSphere Application Server Network Deployment cell is a single trust domain, so the placement of firewalls between WebSphere Application Server nodes provides no additional security protection, since the firewall must be configured to allow WebSphere Application Server inter-node communication; a breach on one node compromises all nodes and, in the same vein, using a separate management network provides no additional security protection - again, because a breach on one WebSphere Application Server node, on either management or application processes running on that node, will compromise all WebSphere Application Server Network Deployment processes in the cell.

Specific to firewalls, you need to determine the ports in use in your environment and determine the ports in use between WebSphere Application Server Network Deployment processes. Refer to this advanced security hardening article for a discussion and diagram on the connections between various Network Deployment processes and to the Information Center for a list of the default ports in use, then determine the specific ports in use for your environment and proceed to configure the firewall.

With regard to assistance or support for firewall configuration, the WebSphere Application Server Product Support Policy on firewalls is as follows:

"WAS [sic] requires a network connection between all WAS components. If there is a firewall along that connection it should be transparent to WAS and as such not effect WAS operation.  The Support Center will accept WAS usage and defect related service requests for WAS even when there is a firewall implemented between WAS components. During troubleshooting process, IBM may require that the problem be recreated without a firewall being in the flow between WAS DM and its Agents to check if the problem is related to the implemented firewall or not."

Turning to the use of a management network, the WebSphere Application Server default is for WebSphere Application Server profiles to use all of the network interfaces on a given node that are available for use, but WebSphere Application Server can be configured to use only a specific interface (which would correspond to an administrative network). Refer to the Information Center for information on configuring a WebSphere Application Server profile to use just a single interface (Note that WebSphere Application Server cannot be configured to use a subset of interfaces, only "all" interfaces or a single interface).


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.

Resources

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=471144
ArticleTitle=Q & A: Frequently asked questions about WebSphere Application Server security
publish-date=05032014