I have a web application that have standard form authentication declared, like this:
<login-config>
<auth-method>FORM</auth-method>
<realm-name>ldap-realm</realm-name>
<form-login-config>
<form-login-page>/home</form-login-page>
<form-error-page>/home?error=true</form-error-page>
</form-login-config>
</login-config>
I have the ldap-realm declared in my Glassfish server, with all the necessary credentials to connect to my LDAP server.
The issue is this:
On Glassfish V2 if I deploy this application, when trying to login with a wrong user (or existing user but bad password) I get redirected to the URL declared in <form-error-page> (/home?error=true) and this page displays a user friendly error message such as “You’ve failed to authenticate bla bla”. Also, if I look in the logs at this point I see a WARN message telling me that the credentials entered by the user cannot be authenticated against the LDAP server.
On Glassfish V3 (tried on both 3.0 and 3.1) when I deploy the exact same application, and have the exact same ldap-realm configured in GF, when the user tries to authenticate with CORRECT credentials all goes ok, but when he enters bad user or good user / bad password I get a 404 page not found error instead of getting redirected to the URL from <form-error-page>. More to the point, what happends is that upon an invalid authentication the user sees the HTML page that I’ve declared for 404 errors instead of the form-error-page. Also in the glassfish log I now have an exception stacktrace like this:
[#|2012-01-05T16:49:28.878+0100|WARNING|glassfish3.1|javax.enterprise.system.container.web.com.sun.web.security|_ThreadID=130;_ThreadName=Thread-1;|Exception
com.sun.enterprise.security.auth.login.common.LoginException: Login failed: Failed file login for aaaa.
at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:394)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:240)
at com.sun.enterprise.security.auth.login.LoginContextDriver.login(LoginContextDriver.java:153)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:483)
at com.sun.web.security.RealmAdapter.authenticate(RealmAdapter.java:425)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:269)
at org.apache.catalina.authenticator.AuthenticatorBase.processSecurityCheck(AuthenticatorBase.java:909)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:546)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.auth.login.LoginException: Failed file login for aaaa.
at com.sun.enterprise.security.auth.login.FileLoginModule.authenticate(FileLoginModule.java:84)
at com.sun.enterprise.security.auth.login.PasswordLoginModule.authenticateUser(PasswordLoginModule.java:117)
at com.sun.appserv.security.AppservPasswordLoginModule.login(AppservPasswordLoginModule.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:579)
at com.sun.enterprise.security.auth.login.LoginContextDriver.doPasswordLogin(LoginContextDriver.java:382)
Honestly, I’m pretty stumped. The ldap-realm is correctlly defined, since a VALID authentication works ok. Also the URL for the form-error-page is valid because if I enter it manually in the address bar I get the authentication error page. The only thing I’m thinking of doing is make a custom LdapRealm implementation and no longer throw that exception when authentication fails. But this is not very cool.
My question is then, does anyone know if there’s a difference in the way Glassfish V2 and V3 handle failed authentications? Is there some extra config param available to Glassfish V3 that will make it return the form-error-page upon an invalid user authentication instead of throwing an exception and returning a 404?
Well, no one answered, and I’ve found a workaround albeit not a good one. As stated in the question, I have the url for
<form-error-page>declared as a servlet and this is never displayed in GF3. What I did is ismply replace that url to one that points to a static file (like /loginError.html) and in that static page do a redirect to the desired url (that of the servlet that handles login errors). This way I get the desired behaviour.