tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: Still having problem retrieving user value from ISAPI Filter for authentication
Date Tue, 22 Jun 2010 14:05:33 GMT
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:pid@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:pid@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:pid@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@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.



Mime
View raw message