WebSphere Application Server Interview Questions - Part -1.1

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

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

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

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

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

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

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?

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