Martin Vlcek (Migrated from SEC-1003) said:
Currently NTLM authentication is initiated (by NtlmProcessingFilter) on the first application page the user views, even is is not secured. That means that a user with e.g. Firefox (not set to do NTLM) will get a login popup, even though the page is accessible without login.
Setting forceIdentification to false does not work either, as in this case NTLM is never initiated.
Solution: initiate NTLM from the NTLMProcessingFilterEntryPoint
Add the following method to NTLMProcessingFilter to allow setting the BEGIN-State from outside:
Change NtlmProcessingFilterEntryPoint to initiate NTLM, if the page requires authentication:
Set forceIdentification for the filter to false – using true will exhibit the current behavior.
As it is no more possible to have unsecured pages (even with forceIdentification=false), this issue should not be qualified as “Improvement” and “Minor”, but really qualified as a “Bug” and “Major”.
Could you requalify this issue ?
Danny Dion said:
I agree with you, this is a MAJOR BUG and it would be nice if it got fixed in the next release...
Luke Taylor said:
The original Acegi NTLM contribution treated NTLM purely as an SSO solution for use within a Windows LAN. It wasn't intended to support Firefox or on-demand authentication.
In any case, we have decided to drop NTLM from the 3.0 codebase. It is difficult to work with and maintain and Mike Wiesner has been putting together a Kerberos-based alternative which is part of the new Security Extensions project.