TAI stands for “Trust Association Interceptor”. A TAI runs in WebSphere Application Server and is invoked for requests that are not authenticated yet. TAIs are invoked in a chain. If any of the TAIs in the chain authenticates the user the others will no longer be invoked. In case no TAI handles the request the default WebSphere behavior for the addressed application will be invoked. For example, the request might trigger basic authentication or it might redirect (HTTP 302) the HTTP request to a custom login page.
If all TAIs are disabled and if a URI is “protected” (from a WebSphere point of view) and if a user has not authenticated to WebSphere (meaning there is not valid LTPAToken2 cookie on the request), then the “forms” or “basic auth” form of authentication is invoked by WebSphere. So, for example, hitting “/wps/myportal” in WebSphere Portal will trigger the Portal login page if you don’t have a valid LTPAToken2 Cookie since WebSphere Portal has declared “/wps/myportal” a protected URI. An LTPAToken2 cookie is evidence that you are an authenticated user in WebSphere.
There is a class of software products know as “authentication proxies”. These products front-end Portal and other software that respond to HTTP web requests (I.e web servers like Apache, etc). Their job is to monitor all inbound requests and force an “SSO” login if the page is “protected” from the security proxy point of view. Some security proxies have an explicit list of URIs that they protect. These products include WebSEAL (IBM) and SiteMinder (CA). In this case, say with WebSphere Portal, you would “protect” “/wps/myportal” in the security proxy which would require a user to authenticate to the proxy prior to ever reaching the back-end Portals. Note that when authenticated to the security proxy, you get a cookie (or some other form of authentication) in your browser that is unique to that proxy indicating as such.
There are other security proxy (SSO) solutions that default to protecting every URI; e.g. SAML. SAML (Security Assertion Markup Language) is a complex topic, but it is not uncommon for every inbound URI to be “protected” by default.
Now we are ready to describe TAIs. A TAI is a piece of software that run in WebSphere that, for instance, gets configured when there is an external security proxy like mentioned above. The job of the TAI is to recognize that an inbound URI belongs to that TAI (e.g. a security proxy protected URI) and determine if the URI “clears” WebSphere security due to the authentication already having been handled at the security proxy. If it does, then ultimately a LTPAToken2 cookie is set on the response and as far as WebSphere is concerned, any subsequent request containing a valid LTPAToken2 cookie does not need to be challenged further. Typically, these TAIs would communicate with their security proxies (running on other machines) to determine if the TAI should claim an HTTP request.
We can now discuss the role of the HTTPBasicAuthTAI that is provided by WebSphere Portal. It is typically used to trigger basic authentication for “/wps/mycontenthandler” requests for webdav authentication. Note that “/wps/contenthander” requests are targetted for both anonymous and authenticated users so no authentication is required. The HTTPBasicAuthTAI is at the top of the list of TAIs in WebSphere. It would be ahead of TAIs for either of WebSEAL or SiteMinder (TAI++) or the TAI for SAML. TAIs are “chained”. This means that TAIs are called “in order”. If any TAI “claims” the URI, then after that TAI processes the request (e.g. authenticates the URI), no other TAIs are called. If the TAI is not able to authenticate the user requesting the URI, then the next TAI in the chain is called.
The HTTPBasicAuthTAI can be used to supercede other TAIs for “special” HTTP requests that are not authenticated by the security proxies mentioned above. HTTPBasicAuthTAI does this via “whitelists” and “blacklists”. For any URI pattern (and these can be regular expressions), if the URI matches a pattern in the “blacklist” he request is immediately passed to the next TAI in the chain. If not, the URI is checked against the “whitelist” patterns. If a pattern in the whitelist matches, HTTPBasicAuthTAI handles the authentication. If no pattern in the whitelist matches, then the HTTP request falls thru to the next TAI in the chain; say the security proxy TAI.
If the HTTP request URI matches the whitelist, then HTTPBasicAuthTAI claims the request and does exactly as the name suggests: it looks for “basic authentication” headers in the request to validate the identity of the user. If the username and password combination in the basic authentication headers does not validate using basic authentication headers in the request, then WebSphere will reject the request. If it does validate, then WebSphere will ultimately do a “set cookie” for LTPAToken2 and future requests with this cookie will be accepted.
In case of security proxies that do not let you exclude URIs from checking, not accepting regular authentication flows for Portal features like XMLAccess or syndication will likely cause issues. One can use the HTTPBasicAuthTAI to execute basic authentication before the other TAIs are invoked and so enable XMLAccess and other URLs that are not really supposed to be handled by the Security Proxy. This is a workaround for security proxies with TAIs one cannot influence (i.e. no whitelist). WebSeal nor SiteMinder do not have this problem since they have explicitly blacklists. In those cases you need to put any URI pattern requiring basic authentication in the HTTPBasicAuthTAI “whitelist”. This would include, for example, “/wps/config” and “/wps/mycontenthander” (which WCM syndication uses with basic authentication). There could be others.