search

spring-projects / spring-security

Spring Security
http://spring.io/projects/spring-security
Apache License 2.0
8.45k stars 5.76k forks source link

SEC-8: Windows NT Domain AuthenticationProvider #269

Closed spring-projects-issues closed 16 years ago

spring-projects-issues commented 18 years ago

["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex](Migrated from ["SEC-8":https://jira.spring.io/browse/SEC-8?redirect=false]) said:

http://opensource.cenqua.com/shaj/ provides a mechanism to authenticate against Windows NT Domains.

See also http://forum.springframework.org/viewtopic.php?p=22163

See also http://forum.springframework.org/viewtopic.php?t=4670 which discusses NTLM authentication and refers to some code that has already been written for this purpose.

spring-projects-issues commented 18 years ago

["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] said:

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

spring-projects-issues commented 18 years ago

["Davide Baroncelli":https://jira.spring.io/secure/ViewProfile.jspa?name=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 commented 18 years ago

["Davide Baroncelli":https://jira.spring.io/secure/ViewProfile.jspa?name=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="authenticationManager" class="net.sf.acegisecurity.providers.ProviderManager">
    <property name="providers">
        <list>
            <bean id="smbAuthenticationProvider"

class="net.sf.acegisecurity.providers.smb.SmbNtlmAuthenticationProvider">

            </bean>
            <ref local="anonymousAuthenticationProvider"/>
        </list>
    </property>
</bean>
spring-projects-issues commented 18 years ago

["Fabio Grassi":https://jira.spring.io/secure/ViewProfile.jspa?name=fabio] 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 commented 18 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 commented 18 years ago

["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] 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 commented 18 years ago

["Rory Winston":https://jira.spring.io/secure/ViewProfile.jspa?name=rwinston] 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 commented 18 years ago

["Rory Winston":https://jira.spring.io/secure/ViewProfile.jspa?name=rwinston] 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 commented 18 years ago

["Rory Winston":https://jira.spring.io/secure/ViewProfile.jspa?name=rwinston] 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 commented 18 years ago

["Aby Herwendo":https://jira.spring.io/secure/ViewProfile.jspa?name=aby] 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 commented 18 years ago

["Aby Herwendo":https://jira.spring.io/secure/ViewProfile.jspa?name=aby] 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 commented 18 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 commented 18 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 commented 18 years ago

["Serguei Bakhteiarov":https://jira.spring.io/secure/ViewProfile.jspa?name=serge] 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 commented 18 years ago

["Fabio Grassi":https://jira.spring.io/secure/ViewProfile.jspa?name=fabio] 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 commented 18 years ago

["Jeff Greene":https://jira.spring.io/secure/ViewProfile.jspa?name=whackity] 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 commented 18 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 commented 18 years ago

["Jeff Greene":https://jira.spring.io/secure/ViewProfile.jspa?name=whackity] 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 commented 18 years ago

["Jara Cesnek":https://jira.spring.io/secure/ViewProfile.jspa?name=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 commented 18 years ago

["Jara Cesnek":https://jira.spring.io/secure/ViewProfile.jspa?name=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 commented 18 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 = ? 
<bean id="daoAuthorizationProvider" class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
    <property name="userDetailsService" ref="jdbcAuthenticationDao"/>
</bean>

<bean id="authenticationProvider" class="org.acegisecurity.providers.smb.SmbNtlmAuthenticationProvider">
    <property name="authorizationProvider" ref="daoAuthorizationProvider"/>
</bean>

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 commented 18 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 commented 18 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] said:

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

spring-projects-issues commented 18 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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 codebase and configuration has been tested against a PDC on our local intranet with success.

spring-projects-issues commented 18 years ago

["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] 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 commented 18 years ago

["Ray Krueger":https://jira.spring.io/secure/ViewProfile.jspa?name=raykrueger] 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 commented 18 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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:

The applicationContext.xml was also reworked and because of its importance to getting the NtlmProcessingFilter to work properly:

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 commented 18 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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 commented 17 years ago

["Amit Jain":https://jira.spring.io/secure/ViewProfile.jspa?name=amitdv] 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 commented 17 years ago

["Amit Jain":https://jira.spring.io/secure/ViewProfile.jspa?name=amitdv] 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 commented 17 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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 commented 17 years ago

["Amit Jain":https://jira.spring.io/secure/ViewProfile.jspa?name=amitdv] 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 commented 17 years ago

["David Sprowls":https://jira.spring.io/secure/ViewProfile.jspa?name=dsprowls] 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 commented 17 years ago

["Amit Jain":https://jira.spring.io/secure/ViewProfile.jspa?name=amitdv] 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.

<filter>
    <filter-name>Acegi Filter Chain Proxy</filter-name>
    <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
    <init-param>
        <param-name>targetClass</param-name>
        <param-value>org.acegisecurity.util.FilterChainProxy</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>Acegi Filter Chain Proxy</filter-name>
    <url-pattern>/**</url-pattern>
</filter-mapping>

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 commented 17 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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 commented 17 years ago

["Tamas SANDOR":https://jira.spring.io/secure/ViewProfile.jspa?name=tsandor] 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 commented 17 years ago

["Sathish Chandramohan":https://jira.spring.io/secure/ViewProfile.jspa?name=sathish_ch] 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 commented 17 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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:

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 commented 17 years ago

["Tamas SANDOR":https://jira.spring.io/secure/ViewProfile.jspa?name=tsandor] 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 commented 17 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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 commented 17 years ago

["Tamas SANDOR":https://jira.spring.io/secure/ViewProfile.jspa?name=tsandor] 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 commented 17 years ago

["xiaobo":https://jira.spring.io/secure/ViewProfile.jspa?name=rainbow] said:

Could anyone tell me how to build the acegi-security with Ntlm support? Command line or kindly send me the jar at xiaobof@juno.com?

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 commented 17 years ago

["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] 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 commented 17 years ago

["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] 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 commented 17 years ago

["Edward Smith":https://jira.spring.io/secure/ViewProfile.jspa?name=macvelli] 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 commented 17 years ago

["Andy Brough":https://jira.spring.io/secure/ViewProfile.jspa?name=caverns] 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 commented 17 years ago

["Deenar Toraskar":https://jira.spring.io/secure/ViewProfile.jspa?name=deenar] 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)

<!--
    always needed for preauthentication / SMB signatures
-->
<init-param>
    <param-name>jcifs.smb.client.domain</param-name>
    <param-value>NYC-USERS</param-value>
</init-param>
<init-param>
    <param-name>jcifs.smb.client.username</param-name>
    <param-value>somenycuser</param-value>
</init-param>
<init-param>
    <param-name>jcifs.smb.client.password</param-name>
    <param-value>AReallyLoooongRandomPassword</param-value>
</init-param>

Hope this helps

Deenar

spring-projects-issues commented 17 years ago

["Andy Brough":https://jira.spring.io/secure/ViewProfile.jspa?name=caverns] 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 commented 17 years ago

["Deenar Toraskar":https://jira.spring.io/secure/ViewProfile.jspa?name=deenar] 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 commented 17 years ago

["Jara Cesnek":https://jira.spring.io/secure/ViewProfile.jspa?name=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.