JbossSecurityMgrRealm problem in Jboss 3.2.4-tomcat 5.0.26

[tfk257]

I have Jboss 3.2.4-tomcat 5.0.26 I am trying to secure my web app with CLIENT-CERT. The problem is that JbossSecurityMgrRealm is the default security manager realm in the embeded tomcat and it cannot be overriden.
It creates the principal of type sun.security.X509.X500Name type. This type is not serializable and when the prinicpal is propagated to the EJB container. Java.io.NotSerializable Exception is thrown

How can I handle this?

Please Help

[cbrettin]

I'm using JBoss 4.00DR4 and I managed to get CLIENT-CERT to work with a servlet, roughtly following the config given in the wiki:
http://www.jboss.org/wiki/Wiki.jsp?page=BaseCertLoginModule

Except that I've used CertRolesLoginModule in jbosssx from CVS and a dynamically loaded login configuration.

I'm not currently using role based security on the EJBs but sessionContext.getCallerPrincipal() returns the principal so I assume a compatible login is occuring, but then I'm using Local invocations, so that may be the differnece.

JbossSecurityMgrRealm simply interfaces tomcat the the JBoss security architecture (it just delegates to a jboss security manager specified in its local JNDI) even the class is not hardwired: it is configured via server.xml (Server/Service/Engine/Realm) in the tomcat sar (look in the deploy dir).
BUT it is not a JBoss realm it is a Catalina one, so you probably don't want to change it (except possibly the certificate subject mapping class)


Hope this helps

[tfk257]

Thanks for the reply


but how to change the subject mapping class?

[cbrettin]

Needing a serializable principal is a bad sign; from this I assume that you are using the beans through the remote interfaces; If you accessed the beans using local calls there would be no need for serialization.

Client-cert authentication relies on the SSL handshake to verify the presented certificate so it is only secure in the local context of the connection - any extension to thirdparties relies on trust relationships which should be carefully examined for security holes (for instance if the remote login is just fowarding the principal and credential you must accept connections only from trusted sources as otherwise clients can just supply the principal and the certificate (= PUBLIC key) to authenticate as anyone they choose.

Also for the least problems the web application and the EJB should be in the same security domain (or at least both in a certificate login domain; normally a JaasSecurityDomain with appropriate login modules).

Assuming that you are sure that you need the serializable principal, in the deploy/jbossweb-tomcat50.sar/server.xml file:



certificatePrincipal is the mapping class name. This class must implement the interface org.jboss.security.CertificatePrincipal which has one method:

public java.security.Principal toPrinicipal(java.security.cert.X509Certificate[] certs);

The built in JBoss class SubjectDNMapping in the config above uses the build in method to get a Principal:
certs[0].getSubjectDN();

There is another built in class for mapping, SerialNumberIssuerDNMapping, which uses the following logic:

BigInteger serialNumber = certs[0].getSerialNumber();
Principal issuer = certs[0].getIssuerDN();
SimplePrincipal principal = new SimplePrincipal(serialNumber+" "+issuer);

SimplePrincipal is serializable, so the get a serializable principal either specify this class in the config above, or use you own implementation of the interface.

When the JBossSecurityMgrRealm has created the principal it uses the assigned security domain (from the web app config) to login using the created principal with the certificate chain as a credential, which is then passed to the configured login modules.

[toren03]

More on jboss-3.2.4 with tomcat-50

I have a slightly different error with setting up CLIENT-CERT. My application requires that I set-up port 8442 for TLS w/o client authorization so in the $JBOSS_HOME/server/default/deploy/jbossweb-tomcat50.sar server.xml file I have the following connector:

 <Connector port="8442" address="${jboss.bind.address}"
 maxThreads="100"
 minSpareThreads="5"
 maxSpareThreads="15"
 scheme="https"
 secure="true"
 clientAuth="false"
 keystoreFile="${jboss.server.home.dir}/../../bin/tomcat.jks"
 keystorePass="RHhyqC7S"
 sslProtocol = "TLS" />

the connector for port 8443 is similar. Otherwise the files are as described in the wiki page: http://www.jboss.org/wiki/Wiki.jsp?page=BaseCertLoginModule

The one difference is that I've used a org.jboss.security.auth.spi.DatabaseServerLoginModule to obtain the roles. Everything works fine until somewher e after the correct role is obtained as the database shows the query in the log. Any ideas or is there some critical information that I should provide? Thanks


11:47:54,220 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing
java.lang.NullPointerException
at org.jboss.security.plugins.JaasSecurityManager.getPrincipal(JaasSecurityManager.java:271)
at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:174)
at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:149)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:92)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)

[cbrettin]

It appears that the security domain you are authenticating in does not have a cache policy (the NPE occurs becauce the policy is used for synchronization).

This policy is should set by the security manager service, (mbean jboss.security:service=JaasSecurityManager) when the JassSecurityDomain registers with the manager service (when the mbean for the domain is started).

Check that you have deployed the SecurityDomain MBean, and that it started properly. But, as the lookup apparently worked, I would guess that your security manager service isn't properly configured (see conf/jboss-service.xml). It is possible that there is not a cache policy associated with the security manager (I imagine the default configuration works, so this will only happen if you change it)

Hope this isn't too confusing

[toren03]

Here is the section from the jboss-service.xml file which I took from the above reference. I think it must be working as without I don't think that the login module would retrieve the subject from the certificate correctly. IThis was the only change (and an addition) to the jboss-service.xml without I don't get an exception, but then it also doesn't find the certificate.

 <!-- setting up the java://jaas/jmx-console realm see login-config.xml -->
 <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
 name="jboss.web:service=SecurityDomain">
 <constructor>
 <arg type="java.lang.String" value="web-console"/>
 </constructor>
 <attribute name="KeyStoreURL">${jboss.server.home.dir}/../../bin/tomcat.jks</attribute>
 <attribute name="KeyStorePass">RHhyqC7S</attribute>
 </mbean>

[derry]

Hi!

I am having exactly the same problem with jboss-3.2.5. Has anyone a solution for this?

CU
Thomas

[tfk257]

Thanks cbrettin for your reply,

But I cannot find any configuration in the server.xml for the Certificate Principal.

Can you please post a copy of the server.xml that has configuration for the CertificatePrincipal.

Thanks again

[tfk257]

In addition to the above,

I have upgraded to JBOSS 3.2.5-tomcat 5.0.26. still can't find where to configure for the certificate principal mapping class in the JbossSecurityMgrRealm. knowing that JbossSecurityMgrRealm is hard coded and there is no way to replace it with other realm. and you can revise the code of the TomcatDeployer Class. It creats a JbossSecurityMgrRealm object and associates it with every web application deploed on JBOSS.

Now what I need is to configure the JbossSecurityMgrRealm for different certificate mapping class.

CAN ANYBODY HELP!!!