I tried rewriting my login module so that it only used text based information (compared string based representations of the given certs) and ended up with the authentication failing in the following stack trace:
java.lang.NullPointerException
at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:303)
at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:219)
at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:94)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:215)
at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionInstanceInterceptor.java:128)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:112)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237)
at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:71)
at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:131)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:125)
at org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:358)
at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:271)
at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:110)
at $Proxy75.create(Unknown Source)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.net.axis.server.EJBProvider.makeNewServiceObject(EJBProvider.java:70)
at org.apache.axis.providers.java.JavaProvider.getNewServiceObject(JavaProvider.java:206)
at org.apache.axis.providers.java.JavaProvider.getServiceObject(JavaProvider.java:166)
at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:256)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:71)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:153)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:123)
at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:431)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:314)
at org.jboss.net.axis.mail.MailTransportService.processMessage(MailTransportService.java:533)
at org.jboss.net.axis.mail.MailTransportService.pollMail(MailTransportService.java:334)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:208)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:171)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:77)
at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:59)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:366)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:293)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:572)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1700)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:554)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1650)
at org.mortbay.http.HttpServer.service(HttpServer.java:894)
at org.jboss.jetty.Jetty.service(Jetty.java:497)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:816)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:966)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:204)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:504)
So, I removed all my configuration and just tried a simple test
I configured the jmx-console to run under an existing login configuration in the conf/login-config.xml file.
It worked as expected.
I added a JaasSecurityDomain (that referenced the login-configuration in its constructor) to the conf/jboss-service.xml :
after restarting the server and trying to access the jmx-console I (actually my log) was presented with:
java.lang.NullPointerException
at org.jboss.security.plugins.JaasSecurityManager.doesUserHaveRole(JaasSecurityManager.java:303)
at org.jboss.jetty.security.JBossUserRealm$JBossUserPrincipal.isUserInRole(JBossUserRealm.java:166)
at org.mortbay.http.SecurityConstraint.check(SecurityConstraint.java:378)
at org.mortbay.http.HttpContext.checkSecurityContstraints(HttpContext.java:1454)
at org.mortbay.jetty.servlet.WebApplicationContext.checkSecurityContstraints(WebApplicationContext.java:1225)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:234)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:573)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1700)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:554)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1650)
at org.mortbay.http.HttpServer.service(HttpServer.java:894)
at org.jboss.jetty.Jetty.service(Jetty.java:497)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:799)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:949)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:816)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:204)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:504)
So it seems that I have completely missed on how to configure the JaasSecurityDomain, or it is somehow borking the authentication process.
What has JaasSecurityDomain done to cause this NPE? I assume it is the fault of JaasSecurityDomain because it is the only thing that has changed in this simple experiment between a working configuration and a non working one.
Is this expected behavior or have I misunderstood how JaasSecurityDomain functions? Is it not possible to have a security domain registered for a login configuration that does normal logins as well?
Thanks
-jason
On Friday, November 22, 2002, at 08:57 AM, Jason Essington wrote:
I think I understand this part well enough, however, here is what is happening in the case I am having trouble with. I am attempting to authenticate an X509Certificate that has arrived in an email (via jboss.net) I have a request handler that creates a LoginContext and a CallbackHandler and performs the login (successfully).-jason
Everyting has worked as expected so far, but when jboss.net attempts to invoke the requested method on the bean, JBoss wants the credentials authenticated again (still in the same domain), only this time it seems the JaasSecurityManager has no cached credentials to compare, so it falls through to the defaultLogin method where it attempts to use the SecurityAssociationHandler (CallbackHandler) that only knows how to deal with NameCallback and PasswordCallback. Since my login module retrieves the X509Certificate via an ObjectCallback, the login fails at this point with an UnsupportedCallbackException.
I am wondering what has happened to my cached login information?
What would cause JBoss to want to perform the authentication again?
thanks
-jason
On Wednesday, November 20, 2002, at 07:55 PM, Scott M Stark wrote:
Yes, the successful login populates the cache with the authentication info. After
that, only validateCache needs to be able to compare the opaque credentials against
the cache value. If there is no cache the login module is called to authenticate the
credentials and this has to understand what the credentials are and be able to interact
with the handler. The JaasSecurityManager does not care about the credentials other
than needing to be able to compare the raw cached credentials against the invocation
credentials. As long as the credential object implements the Comparable interface this
can be done and is the first check made. If the credential implements equals things will
also work.
�
xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
----- Original Message -----
From: Jason Essington
To: [EMAIL PROTECTED]
Sent: Wednesday, November 20, 2002 4:20 PM
Subject: Re: [JBoss-dev] authenticating using a non-text credential (ObjectCallback)
Right, so the only place comparisons are made is in the validateCache() method. Does the initial login (from the code below) populate the domainCache with CacheInfo for the comparison, or does it need to be done some other way. If the cache is nonexistant or expired login falls through to the defaultLogin method which will cause unsupported callback exceptions.
thanks
-jason
