jcifs.http.NtlmHttpFilter and POST

[Robert Baldock]

Has anyone run into issues with jcifs.http.NtlmHttpFilter and POST
requests?

I'm finding in a web-app protected by this filter that GET requests are
all handled fine.  But all POST requests result in what looks like a 404
being displayed in the browser, even though the JSPs being called by the
POST requests are all running successfully.

I just wondered if I need to set the filter to handle these two types of
request differently.


Robert

[Robert Baldock]

Last month I asked about the use of the jcifs NTLM filter and POST
requests.

At that time I hadn't taken account of the information on the NTLM page
about HTTP POST and protecting sub-content:

http://jcifs.samba.org/src/docs/ntlmhttpauth.html#post

And specifically the fact that you have to add a registry entry in order
for POST requests to work properly in IE.

Having made this change, the issues I have been seeing have gone away.

However, what is puzzling is that we only ever seemed to get these
errors for one URL path of a web-app.

In particular, we have deployed this filter against an instance of
Vignette Portal and never ran into any issues with POST requests in the
/portal/console context.  However, POST requests in /portal/site didn't
work until we made this registry change.

The filter has been configured to monitor everything in the /portal
webapp so I'm wondering whether anyone has any theories as to why this
registry entry is required for one URL path but not another.

Any suggestions would be greatly appreciated.

Thanks.


Robert

[Robert Baldock]

Looking further into this, I found Kevin Tapperson's NTLMPostFilter from
2004 on this page:

http://article.gmane.org/gmane.network.samba.java/3708/

However, when I use the logic in this code in my filter, this check for
an Authorization header:

String msg = httpRequest.getHeader("Authorization");
if ((msg != null) && (msg.startsWith("NTLM "))) ...

always results in a msg with a null value.  As a result, the subsequent
code that tries to fool IE is never actually entered.  The end result is
that POST requests end up being ignored completely by the filter.

Does anyone know why this might be the case?


Robert

[Giampaolo Tomassoni-2]

> -----Original Message-----
> From: jcifs-bounces+giampaolo=tomassoni.biz@...
> [mailto:jcifs-bounces+giampaolo=tomassoni.biz@...] On
> Behalf Of Robert Baldock
> Sent: Thursday, August 21, 2008 12:00 PM
> To: jcifs@...
> Subject: RE: [jcifs] jcifs.http.NtlmHttpFilter and POST
>
> Looking further into this, I found Kevin Tapperson's NTLMPostFilter
> from
> 2004 on this page:
>
> http://article.gmane.org/gmane.network.samba.java/3708/
>
> However, when I use the logic in this code in my filter, this check for
> an Authorization header:
>
> String msg = httpRequest.getHeader("Authorization");
> if ((msg != null) && (msg.startsWith("NTLM "))) ...
>
> always results in a msg with a null value.  As a result, the subsequent
> code that tries to fool IE is never actually entered.  The end result
> is
> that POST requests end up being ignored completely by the filter.
>
> Does anyone know why this might be the case?

My really really broad guess.

NTLM is a per-channel authentication protocol, not a per-request one.

When you post something using an already-authenticated channel (which may
happen with servers configured for keep-alive channels), the POST request
needs not be authenticated again.

If you experience occasional problems in the content of a page or in a post,
it *may* be that the content you can't see or the post you can't submit
happens to run on an already-authenticated channel. If you run without
session support in the client and/or in the server, the NTLMHttpFilter would
issue again an SC_UNAUTHORIZED (404 I think) response code to the browser in
order to force it to authenticate. Unfortunately, since NTLM is a
per-channel protocol and that request isn't the first of the channel, IE
doesn't retries authenticating, but simply reports the error to the user.

More unfortunately, Tomcat and, more generally, J2EE-based content delivery
servers don't provide any easy way to known if an HTTP request is the first
of a channel or not, thereby you may need to disable any keep-alive
functionality in order to solve your issues. I have a custom-made version of
the NTLMHttpFilter which keeps track of the active connections by storing
the authentication state in an expireable map keyed by
SourceIP/SourcePort/DestIP/DestPort (which is the "unique key" TCP/IP adopts
for connections). At a request, the filter inspect the table to see if such
a connection is already known. If this is the case, it forwards the request,
otherwise it starts the NTLM authentication process.

Try tracking you http connections with Wireshark or the like. If you find
this is your case, try disabling keep-alives. If you really want
keep-alives, I can eventually spare my sources, but please note they are
meant for my own app, so you will definitely need to tune them to your own
needs.

Giampaolo


>
>
> Robert

[Robert Baldock]

Giampaolo Tomassoni wrote:

> My really really broad guess.

Many, many thanks for that very detailed response.

I shall explore the options you suggest and see whether we could
implement something like what you suggest.

However, I think for the time being, we may just have to settle for
adding the DisableNTLMPreAuth entry to the registry as this does seem to
resolve the issues we're having with POST and IE6.


Robert

[Michael B Allen]

On Thu, Aug 21, 2008 at 7:18 AM, Giampaolo Tomassoni
<Giampaolo@...> wrote:
>> Does anyone know why this might be the case?
>
> My really really broad guess.
>
> NTLM is a per-channel authentication protocol, not a per-request one.

You probably shouldn't be making really really broad guesses :->

NTLMSSP over HTTP is per-request. At least it's supposed to be. If you
look at IIS, every request is authenticated. But for performance
reasons JCIFS caches the result of an authentication in the user's
session (which also is not tied to channels incedintally).

If IE does NTLM with a server it will proactively initiate NTLMSSP
authentication for POST requests (I don't know how IE decides which
servers it has authenticated with - it's probably based on the
hostname) as described in the NTLM HTTP Filter documentation. In this
case, the filter must be enabled to consume such authentications or IE
will never send the POST data.

The problem is that the OP's config is screwed up and the filter isn't
being engaged properly for the POST targets.

Mike

--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/

[Giampaolo Tomassoni-2]

> -----Original Message-----
> From: jcifs-bounces+giampaolo=tomassoni.biz@...
> [mailto:jcifs-bounces+giampaolo=tomassoni.biz@...] On
> Behalf Of Michael B Allen
> Sent: Thursday, August 21, 2008 8:28 PM
> To: Giampaolo Tomassoni
> Cc: jcifs@...
> Subject: Re: [jcifs] jcifs.http.NtlmHttpFilter and POST
>
> On Thu, Aug 21, 2008 at 7:18 AM, Giampaolo Tomassoni
> <Giampaolo@...> wrote:
> >> Does anyone know why this might be the case?
> >
> > My really really broad guess.
> >
> > NTLM is a per-channel authentication protocol, not a per-request one.
>
> You probably shouldn't be making really really broad guesses :->

What about brainstorming? :)


> NTLMSSP over HTTP is per-request. At least it's supposed to be.

Michael, I can't find were specs explicitly state NTLMSSP shall be
per-request. Instead, as I pointed out in the message
<000d01c89a83$67b0c350$371249f0$@biz>, par. 1.3.1.1 "NTLM
Connection-oriented Call Flow" point 4 of "MS-NLMP NT LAN Manager (NTLM)
Authentication Protocol Specification
(http://msdn.microsoft.com/en-us/library/cc207850.aspx) states:

"If the challenge and the response prove that the client knows the user's
password, the authentication succeeds and the application protocol continues
according to its specification..."

Now, since HTTP/1.1 supports Persistent Connections, to me the "application
protocol" boundary is not around a single request, but instead spans the
whole connection lifetime. Thereby, a single, successful authentication
exchange is sufficient to authenticate the whole channel. Which, by the way,
makes sense to me: there is no easy way to "steal" an open TCP/IP
connection, thereby there is no need to start more authentication exchanges
on the very same channel.


> If you look at IIS, every request is authenticated.

Sorry, no IIS handy. I'll check it out.


> But for performance
> reasons JCIFS caches the result of an authentication in the user's
> session (which also is not tied to channels incedintally).

This is an implementation choice. I suspect IIS doesn't work the same, don't
you agree?


> If IE does NTLM with a server it will proactively initiate NTLMSSP
> authentication for POST requests (I don't know how IE decides which
> servers it has authenticated with - it's probably based on the
> hostname) as described in the NTLM HTTP Filter documentation.

Right, granted.


> In this
> case, the filter must be enabled to consume such authentications or IE
> will never send the POST data.

Ah, right: I saw that empty POSTs only meant to "trigger" an authentication
process. They always happen to be in a new connection, besides... ;)


> The problem is that the OP's config is screwed up and the filter isn't
> being engaged properly for the POST targets.

Ok. Then, I was wrong in my far guessing.

This is also because I forgot that empty POSTs (from authenticated pages? to
protected servers?) always happen to be carried by brand-new connections,
then Robert's POST problem couldn't be related to the keep-alive one...

I should get a Tomtom when I go that far...

Thank you, Mike.

Ok, Robert: Mike is right (in your case :) ) : it can't be the keep-alive
problem troubling your app.


> Mike
>
> --
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/

[Kevin Tapperson]

Hi Robert,

There are a couple of things that I can recommend that you try.

First, from your post ("...when I use the login in this code in my filter..."), it sounds like you've copied the code and you're trying to use it inside another filter.  If this is the case, then I'd recommend that you remove this code from your other filter and use the version that I posted exactly as is.

The second thing is to make sure that this code (NTLMPostFilter) is executed before other filters in the filter chain.  This filter should be the first one in your filter chain.  The order of the filter chain is controlled by the order of the filter-mapping tags in web.xml.

The NTLMPostFilter that I posted was developed for and used with Vignette Portal 7.  It's been in a production environment for about 4-5 years now.  If you have continued trouble, I can see if I can dig up the old web.xml file from the portal to see the exact order of the filters and how they are configured.

--
Kevin Tapperson

On Thu, Aug 21, 2008 at 5:00 AM, Robert Baldock <robert.baldock@...> wrote:

Looking further into this, I found Kevin Tapperson's NTLMPostFilter from
2004 on this page:

http://article.gmane.org/gmane.network.samba.java/3708/

However, when I use the logic in this code in my filter, this check for
an Authorization header:

String msg = httpRequest.getHeader("Authorization");
if ((msg != null) && (msg.startsWith("NTLM "))) ...

always results in a msg with a null value.  As a result, the subsequent
code that tries to fool IE is never actually entered.  The end result is
that POST requests end up being ignored completely by the filter.

Does anyone know why this might be the case?


Robert

[Robert Baldock]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Kevin –

 

Great to get your input – thanks for the reply.

 

I’m glad I’m not the only one who’s had problems with POST, NTLM and Portal 7. ;-)

 

Yes, I did try merging your logic with the main jCIFS NTLM filter so perhaps I should try keeping them separate.

 

 

Robert

 

 

[Robert Baldock]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Kevin –

 

I meant to say, I don’t suppose you have a similar solution for Vignette Collaboration do you? 

 

We have exactly the same issue with POST requests and NTLM there.  As you may know, Collab uses JAAS modules so I wrote a module based around the jCIFS NTLM filter.  I guess the solution there would be to create a module based around your filter and put it in the stack before the current NTLM module is called…

 

 

Robert

 

 

[Kevin Tapperson]

Yes Robert, the same solution should apply to Vignette Collaboration as well.  There's nothing product specific about the NTLMPostFilter.

--
Kevin Tapperson

On Fri, Aug 22, 2008 at 8:52 AM, Robert Baldock <robert.baldock@...> wrote:

Kevin –

 

I meant to say, I don't suppose you have a similar solution for Vignette Collaboration do you? 

 

We have exactly the same issue with POST requests and NTLM there.  As you may know, Collab uses JAAS modules so I wrote a module based around the jCIFS NTLM filter.  I guess the solution there would be to create a module based around your filter and put it in the stack before the current NTLM module is called…

 

 

Robert