WAS Interview Question Part - I

WAS Questions Part-I



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


A) --> WebSphere Application Server queries the registry for user information as well as for administrative operations.
     --> Here are the reasons why WebSphere Application Server will contact the registry:
            
  a)   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 user id
       ----> Converts user id to registry unique-id (for example, LDAP DNS).
       ----> Obtains group information.

           

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

       C) If the subject propagation fails:  Even with subject propagation enabled, if the subject propagation is 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.

      d) When users authenticate for administrative operations : Web, JMX, and so on

    

      e) Whenever an application starts : the role bindings are verified against the registry

      f) Whenever an administrator sets binding information: In the administrative console.



2) Does WebSphere Application Server work with NIS?

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

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

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

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


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.

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

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

12. Why is SWAM usage discouraged?

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

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

Table 1. Login module vs. TAI

Feature	Login module	TAI
IBM proprietary	No, but requires WebSphere Application Server specific code anyway	Yes
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 logins	Yes	No

14)    In which log file garbage collector information will be recorded ? how to enable garbage collector ?

A)  ----> Nativestdout.log Nativestderr.log are GC logs 

    ---> get into the admin console -> application server->select JVM->Java & Process Management->process definition-> Java Virtual Machine.

There u will have an option to enable GC logging.

15)   How can we check the performance of the application server without external monitoring tools?

A)  Through Websphere in build monitoring tool called Tivoli Performance Monitoring under Monitoring and tuning in Admin Console.
                              (or) 

Tivoli Performance Viewer (TPV): It enables the administrators and programmers to monitor the overall health of the WebSphere Application Server without leaving the Admin console.
From TPV, you can view current activity or log Performance Monitoring Infrastructure(PMI) for the following:



- System resources such as CPU utilization.
- WebSphere pools and queues such as DB connection pool.
- Customer Application data such as servlet response time.