0 Replies Latest reply on Nov 18, 2010 6:20 PM by Todd Gould

    BaseCertLoginModule getting null principle over SSlBisocket to JMS Topic

    Todd Gould Novice



      I'm attempting to use the BaseCertLoginModule to control access to a session bean method and ultimately this method's ability to pub to a JMS topic.  However, while I believe I have faitfully replicated what the relevant documentation says about this module, no matter what I do, the login() always fails.  The cause appears to be obvious in that BaseCertLoginModule.getAliasAndCert() method's invocation of the CallbackHandler always returns with a warning that the "CallbackHandler did not provide a certificate".  I'm am not sure what I am doing wrong in my setup, but would greatly appreciate any and all help as all of my attempts end up in the same null principle problem.


      Here is an extract from my log showing the core of the problem...


      14:48:29,097 INFO  [STDOUT] done seeding SecureRandom
      14:48:29,143 TRACE [BaseCertLoginModule] initialize
      14:48:29,143 TRACE [BaseCertLoginModule] Security domain: my-realm
      14:48:29,143 TRACE [BaseCertLoginModule] securityDomain=java:/jaas/my-realm
      14:48:29,159 TRACE [BaseCertLoginModule] found domain: org.jboss.security.plugins.JaasSecurityDomain
      14:48:29,159 TRACE [BaseCertLoginModule] exit: initialize(Subject, CallbackHandler, Map, Map)
      14:48:29,159 TRACE [BaseCertLoginModule] enter: login()
      14:48:29,159 TRACE [BaseCertLoginModule] login
      14:48:29,175 TRACE [BaseCertLoginModule] enter: getAliasAndCert()
      14:48:29,175 WARN  [BaseCertLoginModule] CallbackHandler did not provide a certificate
      14:48:29,175 TRACE [BaseCertLoginModule] exit: getAliasAndCert()
      14:48:29,175 TRACE [BaseCertLoginModule] Authenticating as unauthenticatedIdentity=null
      14:48:29,190 TRACE [BaseCertLoginModule] enter: validateCredentail(String, X509Certificate)


      My jboss-service.xml contains the following definition


      <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
               <arg type="java.lang.String" value="my-realm"></arg>
            <attribute name="KeyStoreURL">resource:server.keystore</attribute>
            <attribute name="KeyStorePass">mypass</attribute>


      and my login-config.xml contains:



      <application-policy name="my-realm">
            <login-module code="org.jboss.security.auth.spi.BaseCertLoginModule"
                flag = "required">
                <module-option name="password-stacking">useFirstPass</module-option>
                <module-option name="securityDomain">java:/jaas/my-realm</module-option>
                <!-- Note: that I have tried both with and without this to no avail.....
                <module-option name="principalClass">org.jboss.security.auth.certs.SubjectCNMapping</module-option>


            <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
              <module-option name="password-stacking">useFirstPass</module-option>
              <module-option name="usersProperties">props/my-users.properties</module-option>
              <module-option name="rolesProperties">props/my-roles.properties</module-option>



      The jboss.xml file deployed with the session bean contain a mapping to the realm:




      Both my keystore (and trustore as I have also tried this) contain this self-signed cert:



      Keystore type: jks
      Keystore provider: SUN


      Your keystore contains 1 entry


      Alias name: cn=cs3, ou=soa, o=co, st=co, c=us
      Creation date: Nov 17, 2010
      Entry type: keyEntry
      Certificate chain length: 1
      Owner: CN=CS3, OU=SOA, O=CO, L=Colorado Springs, ST=CO, C=US
      Issuer: CN=CS3, OU=SOA, O=CO, L=Colorado Springs, ST=CO, C=US
      Serial number: 4ce463ad
      Valid from: Wed Nov 17 16:22:21 MST 2010 until: Sat Nov 14 16:22:21 MST 2020
      Certificate fingerprints:
               MD5:  63:99:89:B1:96:E5:DC:8D:AB:E1:2E:41:14:55:7D:E5
               SHA1: C5:AE:D3:54:0C:2B:1F:51:82:88:F8:CD:0D:DC:4C:28:C9:16:4B:55





      The props/my-roles.properties contains the following various attemtps to match what is in the self-signed cert (but I don't think we are even getting this far yet as we have a null principle...):


      CN\=CS3,\ OU\=SOA,\ O\=CO,\ ST\=CO,\ C\=US=WRITE_ROLE
      CN\=cs3,\ OU\=soa,\ O\=co,\ ST\=co,\ C\=us=WRITE_ROLE
      cn\=cs3,\ ou\=soa,\ o\=co,\ st\=co,\ c\=us=WRITE_ROLE



      I have added the following to my JAVA_OPTS before starting JBoss:


      -Djavax.net.debug=ssl,handshake -Djavax.net.ssl.keyStore=%JBOSS_HOME%\server\default\conf\server.keystore -Djavax.net.ssl.keyStorePassword=mypass-Djavax.net.ssl.trustStore=%JBOSS_HOME%\server\default\conf\truststore.keystore -Djavax.net.ssl.trustStorePassword=mypass


      The JMS topic is defined like this:



      <mbean code="org.jboss.jms.server.destination.TopicService"
            <depends optional-attribute-name="ServerPeer">jboss.messaging:service=CS3-ServerPeer</depends>
          <attribute name="JNDIName">/topic/TopicA</attribute>


            <attribute name="SecurityConfig">
                  <role name="WRITE_ROLE"
                  create="false" read="true" write="true"/>
                  <role name="READ_ROLE"
                  create="false" read="true" write="false"/>



      The referenced CS3-ServerPeer is defined:



      <mbean code="org.jboss.jms.server.ServerPeer"




            <!-- The unique id of the server peer - in a cluster each node MUST have a unique value - must be an integer -->


            <attribute name="ServerPeerID">${jboss.messaging.ServerPeerID:0}</attribute>


            <!-- The default JNDI context to use for queues when they are deployed without specifying one -->


            <attribute name="DefaultQueueJNDIContext">/queue</attribute>


            <!-- The default JNDI context to use for topics when they are deployed without specifying one -->


            <attribute name="DefaultTopicJNDIContext">/topic</attribute>


            <attribute name="PostOffice">jboss.messaging:service=PostOffice</attribute>


            <!-- The default Dead Letter Queue (DLQ) to use for destinations.

                 This can be overridden on a per destinatin basis -->


            <attribute name="DefaultDLQ">jboss.messaging.destination:service=Queue,name=DLQ</attribute>


            <!-- The default maximum number of times to attempt delivery of a message before sending to the DLQ (if configured).

                 This can be overridden on a per destinatin basis -->


            <attribute name="DefaultMaxDeliveryAttempts">10</attribute>


            <!-- The default Expiry Queue to use for destinations. This can be overridden on a per destinatin basis -->


            <attribute name="DefaultExpiryQueue">jboss.messaging.destination:service=Queue,name=ExpiryQueue</attribute>


            <!-- The default redelivery delay to impose. This can be overridden on a per destination basis -->


            <attribute name="DefaultRedeliveryDelay">0</attribute>


            <!-- The periodicity of the message counter manager enquiring on queues for statistics -->


            <attribute name="MessageCounterSamplePeriod">5000</attribute>


            <!-- The maximum amount of time for a client to wait for failover to start on the server side after

                 it has detected failure -->


            <attribute name="FailoverStartTimeout">60000</attribute>


            <!-- The maximum amount of time for a client to wait for failover to complete on the server side after

                 it has detected failure -->


            <attribute name="FailoverCompleteTimeout">300000</attribute>


            <attribute name="StrictTck">false</attribute>


            <!-- The maximum number of days results to maintain in the message counter history -->


            <attribute name="DefaultMessageCounterHistoryDayLimit">-1</attribute>


            <!-- The name of the connection factory to use for creating connections between nodes to pull messages -->


            <attribute name="ClusterPullConnectionFactoryName">jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory</attribute>


            <!-- When redistributing messages in the cluster. Do we need to preserve the order of messages received

                  by a particular consumer from a particular producer? -->


            <attribute name="DefaultPreserveOrdering">false</attribute>


            <!-- Max. time to hold previously delivered messages back waiting for clients to reconnect after failover -->


            <attribute name="RecoverDeliveriesTimeout">300000</attribute>


            <!-- Set to true to enable message counters that can be viewed via JMX -->


            <attribute name="EnableMessageCounters">false</attribute>


            <!-- The password used by the message sucker connections to create connections.


            <attribute name="SuckerPassword"></attribute>



            <!-- The name of the server aspects configuration resource

            <attribute name="ServerAopConfig">aop/jboss-aop-messaging-server.xml</attribute>


            <!-- The name of the client aspects configuration resource

              <attribute name="ClientAopConfig">aop/jboss-aop-messaging-client.xml</attribute>



            <depends optional-attribute-name="PersistenceManager">jboss.messaging:service=PersistenceManager</depends>


            <depends optional-attribute-name="JMSUserManager">jboss.messaging:service=JMSUserManager</depends>




            <depends optional-attribute-name="SecurityStore"






      It references this in the remoting-sslbisocket-service.xml:



      <mbean code="org.jboss.remoting.security.SSLSocketBuilder"
                display-name="SSL Server Socket Factory Builder">
                 IMPORTANT - If making ANY customizations, this MUST be set to false.
                 Otherwise, will used default settings and the following attributes will be ignored.
            <attribute name="UseSSLServerSocketFactory">false</attribute>
            <!-- This is the url string to the key store to use -->
            <attribute name="KeyStoreURL">${jboss.server.home.url}/conf/server.keystore</attribute>

            <!-- The password for the key store -->
            <attribute name="KeyStorePassword">mypass</attribute>
            <!-- The password for the keys (will use KeystorePassword if this is not set explicitly. -->
            <attribute name="KeyPassword">mypass</attribute>


            <!-- The protocol for the SSLContext. Default is TLS. -->
            <attribute name="SecureSocketProtocol">TLS</attribute>
            <!-- The algorithm for the key manager factory.  Default is SunX509. -->
            <attribute name="KeyStoreAlgorithm">SunX509</attribute>
                 The type to be used for the key store.
                 Defaults to JKS. Some acceptable values are JKS (Java Keystore - Sun's keystore format),
                 JCEKS (Java Cryptography Extension keystore - More secure version of JKS), and
                 PKCS12 (Public-Key Cryptography Standards #12 keystore - RSA's Personal Information
                 Exchange Syntax Standard). These are not case sensitive.
            <attribute name="KeyStoreType">JKS</attribute>



      The problem seems to be when attempting to connect to the JMS Topic.  From debugging into the BaseCertLoginModule and surrounding classes, I can tell that the associated Principal is indeeed null (as is consistent with the CallbackHandler not returing a certificate.  However, I cannot seem to determine what else I need to do to have the CallBackHandler find the certificate and proceed on within the LoginModule as desired.  Any and all help will be greatly appreciated.