SEC-8: Windows NT Domain AuthenticationProvider about spring-security

[spring-projects-issues]

Ben Alex said:

Also consider http://jcifs.samba.org/src/docs/ntlmhttpauth.html

[spring-projects-issues]

Davide Baroncelli said:

This is the initial version of the code I wrote: seems to work pretty well, but I didn’t test it extensively, yet. It is mostly a refactoring to acegi 0.8.2 interfaces of the jcifs classes.

[spring-projects-issues]

Davide Baroncelli said:

In order to use the code I wrote one has to define a ntlm entry point:

and then use it as the main entry point in securityenforcementfilter:

The ntlm filter should be added to the chain:

```



```

and then the smb AuthenticationProvider must be added to the authentication manager in order to validate the ntlm token and complete it with the roles extracted from a delegate authentication provider (set with the “authorizationProvider” property into the smb authentication provider).

```



<bean id=“smbAuthenticationProvider”
```

class=“net.sf.acegisecurity.providers.smb.SmbNtlmAuthenticationProvider”>

[spring-projects-issues]

Fabio Grassi said:

I would like very much to see this feature included even before 1.0 ships and I’m willing to contribute.

I have started some time ago an attempt to integrate acegy with jcifs. Generally speaking the code written by Davide looks better than mine, but I’m not convinced about the way jcifs.Config is initialized.

In particular I think that configuration properties like net.sf.acegisecurity.ui.ntlm.NtlmProcessingFilter.setDefaultDomain should delegate to the underlying jcifs.Config, otherwise we run the risk of having the Filter not perfectly alligned to the jcifs classes it uses.

Even better, as many jcifs classes use Config to assign private static final variable, I think the initialization should be done directly on the Config object via MethodInvokingFactoryBean and then used internally by acegy integration classes.

What do you think? Cheers, Fabio.

[spring-projects-issues]

David Sprowls said:

The attached code does not support authentication against a local machine because it always trys to locate a master browser on the network. I have attached a slightly modified version of NtlmProcessingFilter that takes an extra parameter to indicate whether is should attempt to locate the master browser.

[spring-projects-issues]

Ben Alex said:

Moved the code into the “sandbox” directory within CVS. Some issues preventing it from being put into core are related to uncertainty with licensing of the NtlmProcessingFilter.java contribution, plus a lack of unit tests. If anyone wants to volunteer to write unit tests and/or refactor NtlmProcessingFilter, it would be good.

[spring-projects-issues]

Rory Winston said:

Is there any chance of getting an example of a working config using Acegi and NTLM, with the current Acegi CVS HEAD? I cant seem to get it to work, I have used the example above as a basis, but am obviously missing something….any help much appreciated! I think this feature would be a very valuable addition – many institutions (including a lot of banks) rely on internal NTLM authentication for their Intranet applications.

[spring-projects-issues]

Rory Winston said:

Got it to work, with a bit of tweaking. Ran into a couple of issues when using an InMemoryDaoImpl for the authorization store, which necesssitated a couple of changes, otherwise it workd great. Would be very keen to see this get into 1.0 to save me from having to do source builds.

[spring-projects-issues]

Rory Winston said:

I have created a blog entry on how I got Acegi to work, if anyone’s interested:

http://www.researchkitchen.co.uk/blog/archives/55

I did have to make some minor code changes, the validity of which I’m still not sure about.

[spring-projects-issues]

Aby Herwendo said:

I’d like to authenticate user using NTLM as an UI, and then get user details from Active Directory/LDAP.
It is possible to use AD/LDAP provided in sandbox, but using NTLM as UI is more convenient way to get seamless authentication on Windows box.

The problem is, by using NTLM, we can’t get user password to authenticate it against LDAP.
Yes, we can use another approach, read LDAP using any account which able to search it.
But I’d rather use current user authentication to search LDAP.

Can anyone help it?

[spring-projects-issues]

Aby Herwendo said:

The code in the sandbox did not work fine.

Especially on the nature of NTLM authentication which was not properly handled in the filter, as the right one provided in the code by jcifs.
And NtlmAuthenticationToken must give password which is the contract of UsernamePasswordAuthenticationToken.

And the other one that, NTLM doesn’t give password explicitly, instead of hashed.

Please find attached, which work fine with acegi 1.0.0-RC1 and jcifs 1.2.7

[spring-projects-issues]

David Sprowls said:

Actually the code does work; however, it was initially written against version 0.8. I know of at least two other people besides myself who are using it. My comments that follow are using jcifs 1.2.5 and acegi 0.83.

NtlmAuthenticationToken does provide access to the password from NtlmPasswordAuthentication via getCredentials, which will always return null in a web application scenario as noted in the javadoc for NtlmPasswordAuthentication.getPassword. I think AbstractAuthenticationToken is a more appropriate ancestor since a ntlm challenge is being used instead of an actual password.

It is the job of NtlmProcessingFilter do negotiate the ntlm challenge when ever the browser supplies an authorization header containing ntlm. Except when negotiating this challenge, the authorization header is going to be empty or at least not contain ntlm. I believe your changes will then force renegotiation of the challenge on every new web request, unless you are forcing a single entry point into your application. The current NtlmProcessingFilter merely checks to see if a ntlm negotiation has been initiated and completes it. This should only happen when the user is not authenticated, so it is not necessary to check whether the user is already authenticated in NtlmProcessingFilter.doFilter.

Now what I believe is called repeatedly on every request is the authenticate method on the authentication manager. In this case SmbNtlmAuthenticationProvider.authenticate which then calls performAuthentication which invokes SmbSession.logon(dc, ntlm). This means that authentication is performed against the domain controller on every request using the ntlm challenge stored in the authentication object. This works fine until the smbSession timesout, and then the ntlm challenge is no longer valid and a new session must be established using the same prodedure as the initial login. This seems unnecessary to me, and I am probably going to add a check to see whether the user is already authenticated before performing this call. This may have been rectified in acegi 0.90.

I will be upgrading to acegi 1.0 tomorrow, and will update my post if it changes anything.

[spring-projects-issues]

David Sprowls said:

It appears that your changes to NtlmProcessingFilter force the fallback authentication mechanism whenever the authorization header does not contain ntlm. I am guessing that you must have the same entry point configured for NtlmProcessingFilter as for SecurityEnforcementFilter. This should cause a loop if authentication were to fail.

[spring-projects-issues]

Serguei Bakhteiarov said:

Hello,

Could anybody post the logout sequence?
I have been enjoying the seamless (no prompts) NTLM login for a while, but… you know… sometimes, logout is very important :-)

sincerely,

serge

[spring-projects-issues]

Fabio Grassi said:

I use the following in a Spring Controller:

protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception { HttpSession sessione = request.getSession(false); if (sessione != null) { sessione.invalidate(); } response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return new ModelAndView(new RedirectView(“/”, true)); }

[spring-projects-issues]

Jeff Greene said:

I was able to implement Acegi with NTLM following Rory Winston’s example, but I’m running into a problem. I can authenticate, but after that Internet Explorer does not POST any data. Did anyone else have this problem? It seems to be pretty common after some Googling, but I’m wondering why I am running into this problem and no one else on this list is.

[spring-projects-issues]

David Sprowls said:

I had to put the ntlmFilter on all of my URLs to get IE to work; otherwise, the post parameters seemed to get lost. This was not an issue in mozilla or firefox. This was also with version 0.87, I don’t know if it is still an issue with version 1.0.

[spring-projects-issues]

Jeff Greene said:

Hi David. Here’s my filterChainProxy…

CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /**=httpSessionContextIntegrationFilter,ntlmFilter,securityEnforcementFilter

Also, here is my filterInvocationInterceptor…

CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /admin/**=ROLE_SUPERADMIN,ROLE_ADMIN,ROLE_ASSIGNEE /user/**=ROLE_SUPERADMIN,ROLE_ADMIN,ROLE_ASSIGNEE,ROLE_USER

I think every URL should be getting put through the ntlmFilter according to the above. Do you see anything wrong with what I have? I am using Acegi 1.0 RC1. I have the same experiences with Mozilla and Firefox. It is not an issue.

[spring-projects-issues]

Jara Cesnek said:

Today I upgraded to RC2 and JCIFS 1.2.7 (from acegy 0.9 and 1.2.6 worked fine).

Now everything screwed up.

I use this for web services autentication.
Now XML parser cant parse web service XML because
there some characters before SOAP XML in http post
or contentLength is zero.

I try my old acegi-jcifs implemenattion, implementation from attachment here
even from CVS sandbox head – all failed.

When turn-off acegi SOAP work fine.

Hope final Acegy 1.0 will contain working NTLM.

[spring-projects-issues]

Jara Cesnek said:

Both ntlm implementations (attachment from this thread and head from CVS) contain strange method in file AbstractSmbAuthenticationProvider.

```
public void setAuthorizationProvider(
AuthenticationProvider authorizationProvider) {
this.authorizationProvider = authorizationProvider;
}
```

Is it misspell ?

Can someone post sample XML with using this property.

Can someone explain difference between SmbBasicAuthenticationProvider and SmbNtlmAuthenticationProvider.
When use first and when second.

Thanks

[spring-projects-issues]

David Sprowls said:

The authentication is handled by the SmbNtlmAuthenticationProvider which then needs to determine what permissions should be granted to the user, hence the the authorization provider.

I use a DaoAuthenticationProvider with a JdbcDaoImpl for the user details service. I have the query always return an empty string for the password. This also allows me to easily switch between NTLM authentication and Database Authentication using org.acegisecurity.ui.webapp.AuthenticationProcessingFilter.

Here is an example of the xml that I use.

SELECT user_name, ’’, enabled FROM users WHERE user_name = ? SELECT user_name, role_name FROM user_roles WHERE user_name = ?

```

```

SmbBasicAuthenticationProvider provides samba authentication via the HTTP Basic Authentication mechanism that all browsers should support. It can be used if a browser does not support ntlm authentication, or the browser is running on an operating system other than windows. It can also be specified as a fallback authentication method if you are not sure that all of your client’s browsers will support ntlm authentication. Currently IE and newer Mozilla based browsers support NTLM authentication. IE will not prompt the user for a password. Mozilla browser will prompt the user for an id, password, and domain once per session.

I hope that helps.

[spring-projects-issues]

David Sprowls said:

Here is an updated version of the code in the sandbox.

NtlmProcessingFilter has been modified to allow authentication against a local machine that is not attached to a network. It is also now possible to specify a wins server in the bean definition.

NtlmAuthenticationToken has been updated with 1.0.0-RC2, and had Aby’s changes from above rolled in. I am not sure that this is the best solution; but, it does work.

[spring-projects-issues]

Edward Smith said:

Acegi Security NTLM code for the 03/22/06 CVS snapshot

[spring-projects-issues]

Edward Smith said:

Ok, sorry for the double comment as this is my first time using JIRA. Here are some more notes regarding the zip file I uploaded:
- This file contains the NTML code from the 03/22/06 CVS snapshot and an example applicationContext.xml/web.xml heavily influenced by the researchkitten blog and previous comments from this issue.
- New Class: org.acegisecurity.providers.dao.NTLMDaoAuthenticationProvider extends from DaoAuthenticationProvider and overrides the additionalAuthenticationChecks() method with no implementation.
- Modified Class: org.acegisecurity.providers.smb.NtlmAuthenticationToken was modified to extend UsernamePasswordAuthenticationToken in order to compile against the 03/22/06 snapshot which also allowed some simplification of the code.

This codebase and configuration has been tested against a PDC on our local intranet with success.

[spring-projects-issues]

Ben Alex said:

I received an email from James Adams who volunteered to do some work on this task. It’s not going to require changes to the API, so we can defer it to 1.1.0.

[spring-projects-issues]

Ray Krueger said:

We have support for doing this already by using the JaasAuthenticationProvider in combination with the Tagish Login Modules. Direct support would probably be better than relying on a 3rd party module.

[spring-projects-issues]

Edward Smith said:

The 20060510 NTLM code is an attempt at bringing the original code more in line with the existing Acegi API infrastructure. Therefore, quite a few changes have been made since the 20060323 code drop:
- Completely reworked NtlmProcessingFilter to leverage and extend AbstractProcessingFilter
- Modified NtlmProcessingFilterEntryPoint to leverage two new AuthenticationException classes (BeginNtlmHandshakeException and NtlmType2MessageException) during NTLM negotiations
- Wrapped the call to additionalAuthenticationChecks() in AbstractUserDetailsAuthenticationProvider.authenticate() to bypass if the authentication object is already authenticated
- The ntlmFilter has built-in support for maximum login attempts so that Acegi does not get locked up in an infinite loop with IE if the existing user credentials are no longer valid on the PDC
- Removed the org.acegisecurity.providers.smb package and all related classes
- Removed the NTLMDaoAuthenticationProvider class as it is no longer necessary
- Code was written and executed against the latest JCIFS release (1.2.9)

The applicationContext.xml was also reworked and because of its importance to getting the NtlmProcessingFilter to work properly:
- Notice the exceptionTranslationFilter comes BEFORE the ntlmFilter. This allows NtlmProcessingFilter to leverage exceptionTranslationFilter when performing NTLM negotiations
- The authenticationFailureUrl location needs to be filtered out first in FilterChainProxy so that Acegi does not attempt to authenticate it. I tried to exclude it from the requiresAuthentication() method but the filterSecurityInterceptor throws an AuthenticationException for a null Authentication object which kicks off the ntlmEntryPoint again in exceptionTranslationFilter

I’m sure I’ve forgotten some details about this codebase. However, the Javadocs and key parts of the code are well-documented and should have additional information if needed. Please let me know if there are any questions/concerns/suggestions.

[spring-projects-issues]

Edward Smith said:

The 20060524 code drop has a small change in NtlmProcessingFilter to fix a significant bug. I have added setter methods for three JCIFS configuration properties: smbClientUsername, smbClientPassword, and smbClientSSNLimit. This allows proper configuration of the NTLM filter when a domain controller uses SMB signatures. There are two ways to set up the filter within applicationContext.xml:
1. Set the smbClientUsername and smbClientPassword for the domain controller
2. Set the smbClientSSNLimit to 1

According to the JCIFS site, the first option is the best for scalability but the second option should also work in a pinch.

Thanks goes to Thomas Sandor who raised the issue last week, helped diagnose the problem, and verified the solution worked within his environment.

[spring-projects-issues]

Amit Jain said:

The 20060524 code drop throws the following exception on Weblogic environment

<Jun 9, 2006 4:45:04 PM EDT> <User defined listener org.springframework.web.context.ContextLoaderListener failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘ntlmFilter’ defined in ServletContext resource [/WEB-INF/applicationContext-security.xml]: Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: The authenticationEntryPoint property must be set before NtlmProcessingFilter bean initialization.>

The context file has the following entry for filter chain:



CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/login_error.jsp=httpSessionContextIntegrationFilter
/**=httpSessionContextIntegrationFilter, exceptionTranslationFilter, ntlmFilter, filterSecurityInterceptor

[spring-projects-issues]

Amit Jain said:

The filter order in the Filter chain seems to be incorrect.
I changed the bean context entry to:

CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /login_error.jsp=httpSessionContextIntegrationFilter /**=httpSessionContextIntegrationFilter, ntlmFilter, exceptionTranslationFilter, filterSecurityInterceptor

This has resolved the deployment error.

[spring-projects-issues]

Edward Smith said:

When the order of the ntlmFilter and exceptionTranslationFilter is switched on WebSphere 6.0, deployment works fine but the following exception is thrown in the server console while an HTTP 500 is sent to the browser when attempting to access a protected resource:

[6/12/06 9:24:43:624 CDT] 0000004e WebApp E SRVE0026E: [Servlet Error]-[/index.jsp]: org.acegisecurity.ui.ntlm.BeginNtlmHandshakeException: NTLM
at org.acegisecurity.ui.ntlm.NtlmProcessingFilter.onPreAuthentication(NtlmProcessingFilter.java:286)
at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:241)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:240)
at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:171)
at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:120)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:142)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:77)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:626)
at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:117)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionServletWrapper.handleRequest(JSPExtensionServletWrapper.java:171)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionProcessor.handleRequest(JSPExtensionProcessor.java:230)
at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java:394)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:2837)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:220)
at com.ibm.ws.webcontainer.VirtualHost.handleRequest(VirtualHost.java:204)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1681)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:77)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:421)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:367)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:276)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminaters(NewConnectionInitialReadCallback.java:201)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:103)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:548)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:601)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:934)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1021)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1332)

It is actually expected behavior in this case as the 5/10/06 code drop and up depends on exceptionTranslationFilter coming before ntlmFilter to catch this exception and perform the NTLM negotiations.

It looks like Weblogic is doing initialization in strict order of the beans defined within applicationContext.xml. You may want to try moving the ntlmEntryPoint bean definition above the exceptionTranslationFilter bean definition and see if that fixes the issue instead.

[spring-projects-issues]

Amit Jain said:

This worked. Thanks.

I am trying to make this Acegi NTML work with Spring MVC on Weblogic environment. It looks like the Form Post Data is lost during the NTLM handshake. The request reaches the FormController successfully but does not have the form data.

Any suggestions.

[spring-projects-issues]

David Sprowls said:

Amit,

Here is my comment from earlier in the thread dealing with a similar issue.

I had to put the ntlmFilter on all of my URLs to get IE to work; otherwise, the post parameters seemed to get lost. This was not an issue in mozilla or firefox. This was also with version 0.87, I don’t know if it is still an issue with version 1.0.

Have you tried this? Are you having problems with both IE and Firefox?

[spring-projects-issues]

Amit Jain said:

Thanks David.

I resolved the issue with a minor change is web.xml file of the 05/24/2006 code drop. The change is in the url pattern for filter. This now matches the pattern defined in the proxy configuration in the applicationContext.xml.

```

Acegi Filter Chain Proxy
org.acegisecurity.util.FilterToBeanProxy

targetClass
org.acegisecurity.util.FilterChainProxy

Acegi Filter Chain Proxy /**

```

Since, this change made the application working.

The change ensures that every request has ntlmFilter in the filter chain so, yes, version 1.0.0 also needs ntlmFilter in every IE request.

[spring-projects-issues]

Edward Smith said:

The 20060613 code drop contains the minor changes to applicationContext.xml for Weblogic and web.xml for form post data. Thanks Amit and David for your help.

[spring-projects-issues]

Tamas SANDOR said:

I had the same problem with IE, it was not sending my form data with POST method. Unfortunately the hint for WebLogic does not work on the Tomcat servers (v4.1,v5.5.x), the url-pattern: /\ is not valid, you can only use /*.

After some research, I’ve found in JCIFS documentation:

“Once IE has negotiated NTLM HTTP authentication it will proactively renegotiate NTLM for POST requests for all content associated with the server (based on IP?). Therefore when using HTTP POST requests it is not possible to restrict access to some content on the server as IE will attempt and fail to negotiate NTLM (standard IE error page?). This is a protocol limitation and there does not appear to be a way to convince IE to stop proactively negotiating for POST requests once it has been determined that the server is capable of negotiating NTLM authentication.”

However, I’ve managed to found a workaround for this IE POST problem. If you use a proxy server for your requests, the proxy will do the renegotiation, so the form data will be sent.

Of course, there are some details on the proper POST mechanism (http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication). I don’t know if JCIFS and the ACEGI_NTLM implementation (20060613_Acegi_NTLM.zip) uses the method below:

“A notable exception to the above is the client’s behavior when submitting a POST request (typically employed when the client is sending form data to the server). If the client determines that the server is not the local host, the client will initiate reauthentication for POST requests over the active connection. The client will first submit an empty POST request with a Type 1 message in the “Authorization” header; the server responds with the Type 2 message (in the “WWW-Authenticate” header as shown above). The client then resubmits the POST with the Type 3 message, sending the form data with the request."

Anyway, if anybody else knows a proxy-less solution to this POST problem, please share.

[spring-projects-issues]

Sathish Chandramohan said:

We have used the acegi ntlm authentication api for our web client. It works very well.

We want to use ntlm authentication for our RCP client as well. Has anyone done some

implementations for a rich client.

regards
sathish

[spring-projects-issues]

Edward Smith said:

First, I must apologize for taking so long in getting this out. I have had to wrestle with WebSphere 6.1 and eventually get a patch from IBM due to a nice little bug related to NTLM. WAS 6.1 was closing the HTTP connection on the 401 responses during negotiations while IE requires the connection be kept alive.

Having said that, the fix everyone has been waiting for is now available. The 20060822 code drop was developed against the 2006-07-01 SVN nightly snapshot and should now work properly when IE does a POST regardless of the web container used and without a proxy server. The following changes made it happen:
- Detect the IE/POST condition when a user is already authenticated and perform NTLM negotiations
- Save and restore the existing Authorization object when responding with an NTLM Type 2 message. This preserves the user security information thereby optimizing overall processing time.
- Bypass the usual processing in AbstractProcessingFilter when negotiations are complete so that it flows through like nothing ever happend

Basically, I just made sure to do the NTLM dance for IE without altering the normal Acegi behavior when a user is already authenticated. Thanks Thomas for researching and providing the information on the issue.

[spring-projects-issues]

Tamas SANDOR said:

Edward,

I’ve checked your code in our environment, but after a POST submit, I receive a login_error page coming because of “throw new BypassAuthenticationException()” line you have in NtlmProcessingFIlter. So under IE, I still cannot submit my form.

On the other hand I’ve found some bugs.

1) you use in NtlmProcessingFilter the global variable “bypass”, however it is not intialized at the beginning. You should add: " private boolean bypass; " e.g. after line 76.

2) in method attemptAuthentication() you use " String username = ntlm.getUsername(); ". And after it you try to strip the domain from the beging if “stripDomain” is true. Please note that getUsername will return only the username, without “domain\”. If username field value is e.g. “DOMAIN\username” ntlm.getUsername() will return “username”, ntlm.getDomain() will return ""DOMAIN" and ntlm.getName() will return “DOMAIN\username” as documentation says from jCIFS. So this part should be:

```
String username = ntlm.getName();
String password = "";
if (stripDomain) username = ntlm.getUsername();
```

Please confirm, that NtlmProcessingFilter should be updated. On the otherhand please test if you can make an IE form POST submit.

[spring-projects-issues]

Edward Smith said:

Thanks for the feedback Thomas. It sounds like you might have missed putting org.acegisecurity.ui.AbstractProcessingFilter into your environment. It was modified to a) catch the BypassAuthenticationException, and b) defines the bypass attribute as protected. This is because NtlmProcessingFilter sets the bypass flag while AbstractProcessingFilter uses it to avoid doing normal authentication processing when the user has already been authenticated. Double check to see if the updated AbstractProcessingFilter is in your environment and that it is getting picked up.

The clarification around the username JCIFS specs is also appreciated. I went ahead and modified the NtlmProcessingFilter to use the tertiary operator to set the username local variable which is included in the 20060906 code drop. Please let me know if you come across any more issues.

Ed

[spring-projects-issues]

Tamas SANDOR said:

Thanks for help Edward.

First of all I’ve found that if I pack my classes as a jar and put it into WEB-INF/lib dir, the overriden classes like the AbstractProcessingFilter will not be used from myapp.jar, but from the acegi-security.jar. This could be a classloading problem. So I moved my classes to WEB-INF/classes, this way tomcat will use the right class.

However, POST didn’t succeeded with the new code. Please note that filter-mapping /*_ make no sense in Tomcat. Use can use only /_.

So, I’ve tested my application with jCIFS HTTP Filter and somehow it could submit the POST under IE. So I compared jCIFS’s code with the acegi+ntlm integration code, and found that you should add the following just before the line ntlm = this.authenticate(msg, challenge); in the class NtlmProcessingFilter:

try {
if(( ntlm = NtlmSsp.authenticate( req, res, challenge )) == null ) return;
} catch (ServletException e) {
logger.error(“Error at NtlmSsp.authenticate.”,e);
}

If you have this block in your filter, things start to work, IE does POST the form under Acegi.

I’ve also found that you are not checking for jCIFS properties: enableBasic and insecureBasic, however, it can make sense if an application developer would like to force the basic pop-up to appear. jCIFS’s NtlmHttpFilter checks for these and works properly. I think the integration code should check also.

I hope I could help.

[spring-projects-issues]

xiaobo said:

Could anyone tell me how to build the acegi-security with Ntlm support? Command line or kindly send me the jar at [email protected]?

I’ve checked out the project dated at Jan 2006. However when I used the maven command on acegi-security websites to build it, the errors occured.

Thank you so much!

[spring-projects-issues]

Ben Alex said:

Thanks Edward for your ongoing polishing of this code. It really is appreciated by the community.

I recognise SEC-8 is a popular issue, and would therefore like to incorporate it. Why this code has not been incorporated into SVN so far is because:
1. The license of NtlmProcessingFilter is unclear. We cannot just copy code from another project and relicense it. JCIFS is LGPL so our choices for including it in an Apache licensed project are limited to (a) obtaining a waiver from JCIFS copyright holders (unlikely if not impossible as I do not know whether the copyright owner for JCIFS is clearly established) or (b) rewrite the class in a clean room manner. I favour (b) and the problematic code is less than 500 lines anyway, so it should not represent a considerable undertaking.
2. I do not personally have a Microsoft environment to test out changes. Thus, I really need someone who has a suitable environment to work on this code.
3. We really need unit tests. This is especially important given many users don’t have Microsoft environments to do an integration test. Refactoring of superclasses and interfaces might break the code in the future, so unit tests are especially necessary for this code.
4. I prefer not to see AbstractProcessingFilter modified. It might be better to provide your own filter. BasicProcessingFilter has a similar requirement to skip re-authentication if already authenticated. Maybe look there for ideas.
5. I prefer not to modify AbstractUserDetailsAuthenticationProvider. You probably should write your own AuthenticationProvider instead.

I realise #4 and #5 represent more work, but the inclusion of this capability in SVN will mean less work overall (compared with ongoing repatching of official releases).

Furthermore, if the above comments are adopted it does not change existing functionality. It is therefore eligible for a 1.0.x-series release and won’t need to wait until 1.1.0.

I don’t believe any of the above are particularly difficult to do, and the code is pretty close to usable. If a future code drop addresses the above issues, I will be pleased to add it to SVN and the first patch release thereafter. In the meantime I have removed it from the SVN sandbox as you’re doing a good job with code drops in the JIRA task, and it is better for people to come here to obtain the latest cut of the code.

[spring-projects-issues]

Ben Alex said:

Just further to point #5 on my last comment, you might want to use an interface along the lines of CasAuthoritiesPopulator or LdapUserDetails or X509AuthoritiesPopulator to obtain GrantedAuthority[]s for the authenticated principal. This is the typical pattern we use when an authentication has been externally validated, but we still need the GrantedAuthority[]s in order to compose the Authentication response object. For consideration anyway.

[spring-projects-issues]

Edward Smith said:

Thanks for the feedback Ben, I appreciate it. I will be the first to admit the current code drop needs some further polishing and now I have some ideas on what to do based on your input. Will keep you posted.

[spring-projects-issues]

Andy Brough said:

Can anyone advise me on how to use this with pre-authentication?

I have been using these classes and it’s worked fine when authenticating against a windows 2000 server. However when authenticating against a windows 2003 server only one user can authenticate, any others get an access denied message.

I understand that this is due to pre-authentication as detailed in"SMB Signatures and Windows 2003" here http://jcifs.samba.org/src/docs/ntlmhttpauth.html#proto

Thanks

Andy

[spring-projects-issues]

Deenar Toraskar said:

Andy

We use jcifs with W2K3 servers. To turn on pre-authentication make sure you have the following settings in web.xml or system properties or jcifs.properties. Also ensure that you have jcifs-1.2.9 (preauthentication was partly broken prior to 1.2.8)

```


jcifs.smb.client.domain
NYC-USERS

jcifs.smb.client.username somenycuser jcifs.smb.client.password AReallyLoooongRandomPassword

```

Hope this helps

Deenar

[spring-projects-issues]

Andy Brough said:

Deenar

Thanks for your help. I’m probably being really stupid here, but what does somenycuser and AReallyLoooongRandomPassword have to be set to?

Thanks again

Andy

[spring-projects-issues]

Deenar Toraskar said:

Andy

The user name, password should be a valid Windows username/password combination on the domain you are trying to authenticate users against.

We have created a account (with no privileges, no interactive login’s allowed) purely for preauthentication. Similar to a server/service account.

I am not sure what are the options if you cannot create a server login.

Deenar

[spring-projects-issues]

Jara Cesnek said:

Hi,
I try get to run 20060906_Acegi_NTLM.zip + acegi-security-1.0.3.jar + jcifs-1.2.13.jar.
Realy nothing work and always get /login_error.jsp redirect.

Can me anyone clarify what is mean
“jdoe=PASSWORD,ROLE_USER”
in file applicationContext.xml in 20060906_Acegi_NTLM.zip ?

Isn’t it all about get users and “passwords” from ActiveDirectory ?
Why explicitly write some user info in applicationContext.xml ?

Why this example not use “org.acegisecurity.providers.smb.SmbNtlmAuthenticationProvider”
as seen in oldest acegi-jcif intergration. This approach seem to be more logical
(but not working with new 20060906_Acegi_NTLM.zip ).

Thank.

[spring-projects-issues]

Edward Smith said:

Unfortunately I have not yet attempted to run the most recent NTLM code drop against Acegi 1.0.3 or JCIFS 1.2.13 so I cannot comment on whether or not anything is broken.

The configuration line in question belongs to a simple example of using an in-memory user details service as part of the Acegi authentication workflow. NTLM in Acegi can be considered a two-stage process:

a) Authenticate and acquire the Windows user credentials via NTLM
b) Validate the user ID has access to the web application by doing a security control table lookup

All NTLM ultimately does is give you the Windows user ID of the person accessing your protected web site. You must have another data source to go against that holds the roles and permissions that user has to the given application and this is where a user details service comes in. Normally this information would be stored in a database somewhere instead of applicationContext.xml as the example shows.

The earliest code drops did not take full advantage of the Acegi framework and therefore are not compatible with the latest versions.

[spring-projects-issues]

Mike Cantrell said:

I’ve taken a little time to refactor the source to not require any changes to the existing Acegi framework. It’s pretty crude so far but it gets the job done.

A few things to note:

1) It still uses DaoAuthenticationProvider to populate the user ’s granted authorities. I got around the need to modify AbstractUserDetailsAuthenticationProvider by making a NullPasswordEncoder.

I don’t know if a custom AuthenticationProvider will be necessary since most people will probably have to develop their own UserDetaisService to make this useful (I can’t see it being useful with the any of the existing classes). I have not tested this with anything but the InMemoryDaoImpl and our own UserDetailService. It probably would be a lot cleaner if one was developed though.

2) I hated the idea of relying on the User-Agent header to get around the need for re-authentication on MSIE POSTs (for obvious reasons). The refactor forces all browsers to re-authenticate on POST regardless of the browser. It’s transparent in Firefox and IE (I haven’t tested any other browsers).

3) I don’t have a win2k domain to test pre-authentication against. I have no idea if it’s working.

4) I did not take the time to handle maxLoginTries gracefully.

[spring-projects-issues]

Ben Alex said:

Mike, Edward, Anyone: can someone please verify the latest status of this code, in terms of whether it works and whether there are tests?

[spring-projects-issues]

Edward Smith said:

Hey Ben,

I have not had a chance to look at the code Mike contributed last week so he should have a better idea of its status. Currently I have a completely rewritten NTLM implementation going through QA right now that addresses the following tasks from your post on 29/09/06:

1. I have completely rewritten NtlmProcessingFilter from the ground up so there should be no issues with it being released under the Apache license.
2. Fortunately we have a good Microsoft environment to test against and the rewritten code is currently in QA going against it.
3. Unit tests are going to be next to impossible to create primarily due to the challenge/response nature of NTLM as well as the way JCIFS is written. Essentially one would need to somehow simulate a PDC in order to get unit tests to work.
4. Neither AbstractProcessingFilter nor AbstractUserDetailsAuthenticationProvider has been modified under the refactored code I currently have under QA.

Anyway, that’s the status on what I have going. I have had the rewrite in place for a while locally and have been waiting to release it until it passed our QA mainly due to #3 above. I can either upload it here now for review or in a couple weeks when our QA testing should be complete.

[spring-projects-issues]

Ben Alex said:

Edward, thanks for the detailed information. It sounds as if your patch (in QA) is the closest thing we’ve got to a viable version.

2.0.0 M1 will be released VERY soon. I am happy to include it in M1, with a qualifier it’s likely to change (as is anything in a milestone release). It might be the best approach to get some wider testing exposure and this issue closed after all this time. If you’re comfortable with that, please upload your patch to this issue. Thanks!

[spring-projects-issues]

Edward Smith said:

Thanks Ben and congrats on the upcoming 2.0.0 M1release. The 20070606_Acegi_NTLM code drop has the rewritten code base as well as an updated example applicationContext.xml file. QA results have been positive so far within our local environment so I am excited to see how it performs elsewhere.

One thing to note: I created a class called HttpFilter to contain the common code that seems to appear in several Acegi filters. Currently it is located in the org.acegisecurity.ui.ntlm package where NtlmProcessingFilter extends from it. But if you find it useful, you may want to move it to a more centrally located package and have the other filters that could benefit extend from it as well.

[spring-projects-issues]

Sylvain Mougenot said:

I’m using this component to identify the user and it’s great. (update to 20070606 version)
Is there a way to fallback in an other type of identification if the client does not comply with the NTLM authentication?

More details.
The users are mostly on computer registered on the domain controller.
But some of them would like to use mobile devices to access the application.
Those devices aren’t able to work with neither NTLM nor Basic authentication.

What I’m looking for.
A way to have:
Step 1- NTLM Entry Point taking care of 99% of the user
Step 2- AuthenticationProcessingFilterEntryPoint taking care of those 1% who failed on step 1

[spring-projects-issues]

Sylvain Mougenot said:

After building a new project on top of the sources 20070606_Acegi_NTLM.zip given by Edward Smith, I noticed that the behaviour wasn’t consistent if we use the anonymous provider.

What I noticed.
Maybe I’m wrong but I had to modify the code in order to authenticate the user after he was given an anonymous authentication.

The changes made.
I changed the behaviour of the filter in three points:
1- Do not force NTLM handshake if not required.
I added a Boolean class attribute “forceIdentification” whit a default value “true”. With that value the code behave the same; it forces to start the NTLM handshake the first time a user request encounter the filter but only when authorisations are needed.
In my case it’s not necessary because I’ve a “public” part of the web application.
The NTLM handshake will start only in the EntryPoint. (NtlmProcessingFilterEntryPoint).
2- Allow the filter to overwrite an anonymous authentication.
When the user has already been authenticated and the authentication is one from the anonymous provider allows NTLM filter to process authentication. During this process, backup the former authentication in order to restore it if the process failed.
3- The entry point can restart NTLM handshake like “try again”.
After an AuthenticationCredentialsNotFoundException or a InsufficientAuthenticationException, restart the handshake because this means we failed to authenticate the user. This prevent infinite loop when there is a trouble during authentication done by the filter. (in my case a user was not in the LDAP. I had an exception and the user was redirected to the logout).

In order to detect that the NTLM authentication had already been done, I added a subclass of UsernamePasswordAuthenticationToken having a NTLM flavour : NtlmUsernamePasswordAuthenticationToken.
This allows customizing any provider in order to bypass the problem of an empty password.
With the source code there is a sample LDAP provider and authenticator that are NTLM aware. The behaviour is not the same if the user authentication comes from the NTLM filter.

The code with some maven 2 structure is in the file 20070625_Acegi_NTLM.zip

I hope it helps.

[spring-projects-issues]

Jojo Paderes said:

I’m using the 20070625_Acegi_NTLM.zip for our NTLM+Acegi implementation, however, I’m encountering this exception whenever I try to access a proctected URL:

DEBUG NtlmProcessingFilter – Updated SecurityContextHolder to contain the following Authentication: org.acegisecurity.providers.UsernamePasswordAuthenticationToken@f627ca42: Username:
DEBUG NtlmProcessingFilter – Redirecting to target URL from HTTP Session: http://localhost:8080/myapp/index.html
DEBUG HttpSessionContextIntegrationFilter – SecurityContext stored to HttpSession: ’org.acegisecurity.context.SecurityContextImpl@f627ca42: Authentication: org.acegisecurity.providers.UsernamePasswordAuthenticationToken@f627ca42: Username:
DEBUG HttpSessionContextIntegrationFilter – SecurityContextHolder set to new context, as request processing completed
ERROR [action] – Servlet.service() for servlet action threw exception
java.lang.IllegalStateException: Cannot forward after response has been committed

If I access the URL again after receiving this exception, the web page gets loaded successfully. Removing the response.sendRedirect() call in the HttpFilter.sendRedirect() fixes the issue with the IllegalStateException, however, the redirection to the authenticationFailureUrl will not work.

[spring-projects-issues]

Edward Smith said:

Hey Jojo,

Thanks for the info on the IllegalStateException. Coincidence has it that we are experiencing the same issue on our end whenever a) the session expires, or b) the app server is rebooted. The user can either close/reopen IE 6 to start fresh or hit reload and it works fine. Is the IllegalStateException happening on every protected request for you or only in certain situations? What is your environment like?

Ed

[spring-projects-issues]

Jojo Paderes said:

Hi Edward,

The IllegalStateException happens for all protected requests (all of our URLs are protected). I’m currently using IE6 and Win2k3 domain controller.

As an interim solution, I put a comment on the sendRedirect(request, response, savedRequest.getFullRequestUrl()), the last code line inside the NtlmProcessingFilter.authenticate(). This fixes the IllegalStateException when the session expires. On the other hand, rebooting the server will result to a different error when the user tries to access a different protected page:

2007-07-20 10:19:47,634 DEBUG NtlmProcessingFilter – Processing NTLM Type 3 Message
2007-07-20 10:19:47,634 DEBUG HttpSessionContextIntegrationFilter – SecurityContextHolder set to new context, as request processing completed
2007-07-20 10:19:47,634 WARN [action] – Servlet.service() for servlet action threw exception
java.io.IOException: Not a Type 3 message.
at jcifs.ntlmssp.Type3Message.parse(Type3Message.java:546)
at jcifs.ntlmssp.Type3Message.(Type3Message.java:208)
at org.acegisecurity.ui.ntlm.NtlmProcessingFilter.processType3Message(NtlmProcessingFilter.java:357)
at org.acegisecurity.ui.ntlm.NtlmProcessingFilter.doFilter(NtlmProcessingFilter.java:305)
at org.acegisecurity.ui.ntlm.HttpFilter.doFilter(HttpFilter.java:44)

Workaround for this problem is to close and reopen IE6 and reload the page.

Jojo

[spring-projects-issues]

Edward Smith said:

Ok the 20070727 code drop should hopefully take care of the redirection issues that have been popping up lately. I removed the redirect on successful authentication as my coworker Kent verified with a TCP/IP monitor that the request URL is always the same during NTLM negotiations so redirection is unnecessary. If authentication should fail, I moved the failure URL redirect to the entry point and it appears to work perfectly every time. Please note this requires a small configuration change — just move the authenticationFailureUrl property from NtlmProcessingFilter to NtlmProcessingFilterEntryPoint and it should be good to go.

This drop is a merge of the 20070606, 20070625, and the redirection fixes. Sylvain, I did some light refactoring on your 20070625 code and I hope the intended functionality was preserved. I moved the retry logic from the entry point to the filter and added a retryOnAuthFailure flag which makes it configurable as to whether or not one wants to allow retries on NTLM auth failures. Anyway, please let me know if I missed something.

[spring-projects-issues]

Jojo Paderes said:

I just did some test runs on the 20070727 code drop and the redirection issues were gone now. Thanks Edward for the good work!

The only remaining issue I have now is when I restart the web server while there are some open browser sessions:

WARN [action] – Servlet.service() for servlet action threw exception
java.io.IOException: Not a Type 3 message.
at jcifs.ntlmssp.Type3Message.parse(Type3Message.java:546)
at jcifs.ntlmssp.Type3Message.(Type3Message.java:208)
at org.acegisecurity.ui.ntlm.NtlmProcessingFilter.processType3Message(NtlmProcessingFilter.java:390)
at org.acegisecurity.ui.ntlm.NtlmProcessingFilter.doFilter(NtlmProcessingFilter.java:338)
at org.acegisecurity.ui.ntlm.HttpFilter.doFilter(HttpFilter.java:44)

[spring-projects-issues]

Mike Cantrell said:

It does not handle failed authentication gracefully. If a user is manually entering credentials, it never challenges them again on subsequent requests. If I get some time, I’ll take a look at this.

[spring-projects-issues]

Deenar Toraskar said:

I have used the latest drop, so far so good. I have found that the org.acegisecurity.ui.ntlm.NtlmProcessingFilter checked in does not extend org.acegisecurity.ui.AbstractProcessingFilter. So some of the acegi features cannot be used.
Specifically ACEGI_SECURITY_LAST_EXCEPTION_KEY is not being setup, which is usually set by other processing filters.
This means that my login pages cannot display information about what went wrong. In addition to this the AbstractProcessingFilter does a few other useful things.

Was there some reason this decision was taken?

Regards
Deenar

[spring-projects-issues]

Jara Cesnek said:

I try latest drop and generaly it is working for me. Next week we will try it in production environment. We will see :-))

I must change only tree things.
1) we use agegi as front-ent to webservices not web pages .. so no redirecting allowed at all (/login_error.jsp). Instead of this we send deny status code.(Dont realy sure if this is agegi or this code drop issue)

change:
NtlmProcessingFilterEntryPoint.java

from:
String url = authenticationFailureUrl;
if (!url.startsWith(“http://”) && !url.startsWith(“https://”)) {
url = ((HttpServletRequest) request).getContextPath() + url;
}
resp.sendRedirect(resp.encodeRedirectURL(url));

to:
final HttpSession session = ((HttpServletRequest)request).getSession();
session.setAttribute(NtlmProcessingFilter.STATE_ATTR,NtlmProcessingFilter.BEGIN);
resp.setHeader(“WWW-Authenticate”, “NTLM”);
resp.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
resp.sendError(HttpServletResponse.SC_UNAUTHORIZED,
(authException != null) ? authException.getMessage() : "");

2) Fix “java.io.IOException: Not a Type 3 message.” issue as reported above.

NtlmProcessingFilter.java

from:
final NtlmPasswordAuthentication auth = this.processType3Message(authMessage, session, dcAddress);

to:
try {
final NtlmPasswordAuthentication auth = this.processType3Message(authMessage, session, dcAddress);
logger.debug(“NTLM negotiation complete”);
this.logon(session, dcAddress, auth);
session.setAttribute(STATE_ATTR, COMPLETE);

```
// Do not reauthenticate the user in Acegi during an IE POST
final Authentication myCurrentAuth = SecurityContextHolder.getContext().getAuthentication();
if (myCurrentAuth == null || myCurrentAuth instanceof AnonymousAuthenticationToken) {
logger.debug(“Authenticating user credentials”);
this.authenticate(request, response, session, auth);
}
}catch(IOException ex){
if (ex.getMessage().equals(“Not a Type 3 message.”)){
logger.info(“Not a Type 3 message.”);
session.setAttribute(STATE_ATTR, NEGOTIATE);
this.processType1Message(authMessage, session, dcAddress);
}else{
throw ex;
}
}
```

3) Another detect of MSIE redirect.
We use Delphi as client for our webservices. They have MSIE POST issue too. I choose most simple solution :-)

from:
return (request.getMethod().equalsIgnoreCase(“POST”) && ua != null && ua.indexOf(“MSIE”) != -1));
to:
return (request.getMethod().equalsIgnoreCase(“POST”) && ua != null && ((ua.indexOf(“MSIE”) != -1) || (ua.indexOf(“Borland SOAP”) != -1)));

[spring-projects-issues]

Luke Taylor said:

I’ve added the latest attachment to the main codebase. Thanks a lot for the contribution (complete with maven integration!).

The current LDAP code is in flux due to changes for the 2.0 release (primarily making more use of Spring LDAP) and I’ve altered the code to match the API changes. I’ve also changed the basic LdapAuthenticator interface to take an authentication object as a parameter. I think this should remove the need for a separate NtlmProvider – a specialized BindAuthenticator should then be all that’s required. I provided with an NtlmToken it handles it, otherwise it calls the base class. Let me know if this makes sense.

If anyone can try out the checked in code that would be very useful, as I don’t have any windows machines.

[spring-projects-issues]

Luke Taylor said:

s/I provided/If provided/

[spring-projects-issues]

Luke Taylor said:

In line with the above comment, I’ve removed the custom NtlmAuthenticationProvider as it shouldn’t be necessary.

[spring-projects-issues]

Luke Taylor said:

Could someone with access to a windows network possibly try this out? You can grab one of the latest builds:

http://acegisecurity.sourceforge.net/nightly/

I’m closing this issue, since the code is now in place. Please raise specific issues if you anything amiss.

[spring-projects-issues]

Luke Taylor said:

Ok. Thanks for spotting this. I’ve changed the calls to use “new Integer()”. Please open separate issues in Jira as you come across them. This issue is now closed.

[spring-projects-issues]

Jara Cesnek said:

Hi guys,
I have another bad spot.

NtlmProcessingFilter use session with states (BEGIN, NEGOTIATE, COMPLETE,…).
This is nice, but this not working with asynch request from client browser.
We test is with flex application and this dont work.
Flex make http reguests asynchronous and session state get confused.
(Also AJAX apps maybe dont work.)

For proper filter function response must be build ONLY ON request packet, not session state !!!

[spring-projects-issues]

Jara Cesnek said:

Upper comment apply only for IE+POST (when reAuthOnIEPost() return true).

Other like FireFox, etc .. works fine.