On 22/06/2010 14:45, Savoy, Melinda wrote: > We had been working with JCIFS and chose the Tomcat Connector for IIS because > we're primarily a MS shop and already had IIS in place here. The team lead > who had written this custom code is no longer with the company and I've had > to try and figure out what all he did and then try to implement this Tomcat > connector. > > I've been able to talk to this former team lead and he basically told me the > following on the filter: > > The filter basically takes the request/response and does create an auth value > using the Base64Decoder and Base64Encoder from Sun and we populate a User > object that is then used throughout the session for authentication purposes > within the application as well as initially getting to the index.jsp page. I > was testing, by commenting out the filter in my web.xml, to see if I could > just get to a vanilla index.jsp page that only contained: > <%=getRemoteUser()%> so that I could make certain that I could get that value > which I understood I should be able to without setting up REALM's or auth in > the config. But after getting IIS to talk to Tomcat last week I've been > trying to get this to work and to no avail as of today and therefore the > reason for my post this morning. > > I understood that the ISAPI filter provided the decrypted info that JCIFS had > un decrypting and that is why we chose this route. But it seems like it is a > lot more involved that what I read about and what I've understood from others > on this list - which is fine but it was not as simple as I understood or > misunderstood as the case may be. > > Sorry I cannot be more specific. Hope this helps.
So I'm reading this to mean that the Filter you have commented out is doing the work required to parse the auth header & set the relevant object values. One of the things a Servlet Filter can do is wrap the current request/response objects (see Servlet HttpServletRequestWrapper, HttpServletResponseWrapper interfaces), the wrappers provide methods which override certain request/response methods providing alternative return values. So your custom filter could be decoding the header and overriding the getRemoteUser and getUserPrincipal methods; your app accesses the methods and gets values that are not supplied by Tomcat auth/realm support. (Meaning the JavaRanch advice isn't applicable). So you need to look inside the execute(req, res) method you mentioned earlier to find out what it does, and re-enable the filter. p > -----Original Message----- > From: Pid [mailto:p...@pidster.com] > Sent: Tuesday, June 22, 2010 8:13 AM > To: Tomcat Users List > Subject: Re: Still having problem retrieving user value from ISAPI Filter for > authentication > > On 22/06/2010 13:59, Savoy, Melinda wrote: >> We have a custom filter that we're using because after we get the request >> and response info then I need to use the user value info and get the user >> also authenticated against a legacy system. >> >> But right now I have that commented out in my web.xml so that I can go >> directly to a test index.jsp page and verify that the getRemoteUser() is >> acquiring the user info from ISAPI but ISAPI is not providing that info to >> me via this method. I'm not sure, again, why it shows the info in the log >> but I cannot get to it directly. I'm not sure how Ranier was able to get to >> it as he stated awhile back. > > If there's no auth defined in web.xml then Tomcat isn't going to do anything > - AFAIK the auth valves don't trigger unless the config puts them in the > pipeline. > > If your auth is performed by a custom filter, that is currently commented > out, then you're not going to get very far there either. > > Do you know exactly what the filter does? > Does it decode the header itself and wrap the request/response objects? > > > p > > >> Thanks again. >> >> -----Original Message----- >> From: Pid [mailto:p...@pidster.com] >> Sent: Tuesday, June 22, 2010 7:53 AM >> To: 'Tomcat Users List' >> Subject: Re: Still having problem retrieving user value from ISAPI >> Filter for authentication >> >> On 22/06/2010 13:36, Savoy, Melinda wrote: >>> Thanks Pid, I did do that as well, but I did not see the user value there >>> either. >>> >>> Here is what I got when I did issue the getHeaderNames() and as you can see >>> the authorization shows the encrypted NTLM value but it is not decrypted >>> and I cannot get to the info though the ISAPI log shows the decrypted value >>> which I cannot get to: >>> >>> === MimeHeaders === >>> accept = */* >>> accept-language = en-us >>> connection = Keep-Alive >>> host = localhost >>> user-agent = Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; >>> Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR >>> 3.0.04506.648; InfoPath.2; .NET CLR 3.0.4506.2152; .NET CLR >>> 3.5.30729; MS-RTC LM 8; MS-RTC EA 2) cookie = >>> JSESSIONID=969AE176A965514B845A6E3A9E83A21E >>> authorization = NTLM >>> TlRMTVNTUAADAAAAAAAAAEgAAAAAAAAASAAAAAAAAABIAAAAAAAAAEgAAAAAAAAASAAAA >>> A >>> AAAABIAAAABcKIogUBKAoAAAAP >>> accept-encoding = gzip, deflate >>> content-length = 0 >>> >>> I don't know what I'm doing wrong here. Again, any help is appreciated. >> >> What do you have defined in web.xml for security-config etc? >> >> >> p >> >> >>> Thanks. >>> >>> -----Original Message----- >>> From: Pid [mailto:p...@pidster.com] >>> Sent: Tuesday, June 22, 2010 7:11 AM >>> To: Tomcat Users List >>> Subject: Re: Still having problem retrieving user value from ISAPI >>> Filter for authentication >>> >>> On 22/06/2010 13:05, Marc Boorshtein wrote: >>>> I haven't tried this with IIS, but we had quite the discussion on >>>> this last week with Apache & tomcat with JK. In your server.xml >>>> file add tomcatAuthentication="false" to the AJP connector object. >>>> If you look in the archives of this list for JK_REMOTE_USER there is >>>> a very interesting discussion on the topic. >>> >>> Also, you could iterate through the headers in request.getHeaderNames() to >>> see what's being passed across to Tomcat. >>> >>> >>> p >>> >>> >>>> Marc >>>> >>>> -------------------------------------------------------------------- >>>> - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>> >>> >>> >>> >>> >>> The information contained in this message and any attachments is intended >>> only for the use of the individual or entity to which it is addressed, and >>> may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from >>> disclosure under applicable law. If you are not the intended recipient, >>> you are prohibited from copying, distributing, or using the information. >>> Please contact the sender immediately by return e-mail and delete the >>> original message from your system. >> >> >> >> >> The information contained in this message and any attachments is intended >> only for the use of the individual or entity to which it is addressed, and >> may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from >> disclosure under applicable law. If you are not the intended recipient, you >> are prohibited from copying, distributing, or using the information. Please >> contact the sender immediately by return e-mail and delete the original >> message from your system. > > > > > The information contained in this message and any attachments is intended > only for the use of the individual or entity to which it is addressed, and > may contain information that is PRIVILEGED, CONFIDENTIAL, and exempt from > disclosure under applicable law. If you are not the intended recipient, you > are prohibited from copying, distributing, or using the information. Please > contact the sender immediately by return e-mail and delete the original > message from your system.
signature.asc
Description: OpenPGP digital signature
