http://www.wikio.fr WebSphere And Tivoli Tricks: January 2011

Monday, January 10, 2011

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 Webservers) 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".

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.

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.

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

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

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

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.

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.

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.

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.

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:
  1. Checks the user's password.
  2. Maps certificate information to a userid.
  3. Converts userid to registry uniqueid (for example, LDAP DN).
  4. 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.