-
Bug
-
Resolution: Done
-
Major
-
5.2.2, 5.2.3
-
None
-
False
-
None
-
False
-
We have a use case where we are using jgroups with certificate based authentication (AUTH + X509Token). After upgrading to version 5.2.2 we started to have null pointer exceptions coming from the X509Token.setCertificate() because the keystore_path attribute was null. After checking out the code for version 5.2.2, adding a few log statements and using the modified library on our project, we could also see that all the other X509Token attributes, which were supposed to be initialized, were also null (screenshot below):
This was the configuration that we are using:
<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> <!-- transport protocol --> <TCP bind_port="7800" bind_addr="localhost" thread_pool.min_threads="2" thread_pool.max_threads="8" thread_pool.keep_alive_time="30000" /> <RED/> <TCPPING async_discovery="true" initial_hosts="localhost[7800],localhost[7801]" port_range="0" /> <MERGE3 max_interval="30000" min_interval="10000"/> <FD_SOCK2/> <FD_ALL3 timeout="40000" interval="5000"/> <VERIFY_SUSPECT2 timeout="1500" /> <BARRIER/> <SYM_ENCRYPT sym_algorithm="AES/CBC/PKCS5Padding" sym_iv_length="16" keystore_type="JCEKS" keystore_name="<path_to_keystore>/tcp_jgroups.keystore" store_password="changeit" alias="myKey"/> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> <UNICAST3 /> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="4M"/> <AUTH auth_class="org.jgroups.auth.X509Token" auth_token.auth_value="changeit" auth_token.cert_alias="jgroups_auth" auth_token.keystore_path="<path_to_keystore>/jgroups_auth.keystore" auth_token.keystore_password="changeit" auth_token.cipher_type="RSA" /> <pbcast.GMS print_local_addr="true" join_timeout="2000"/> <UFC max_credits="2M" min_threshold="0.4"/> <MFC max_credits="2M" min_threshold="0.4"/> <FRAG2 frag_size="60K" /> <pbcast.STATE_TRANSFER/> </config>
After a bit of investigation and digging into the code, it seems that for the specific X509Token case, the AUTH protocol has an inconsistency.
When processing and initializing the AUTH protocol, the AUTH.init() method will be called inside ProtocolStack.initProtocolStack() on line 794:
The AUTH.init(), in case the auth_token is of type X509Token, will then call the X509Token.setCertificate() which expects the X509Token attributes to be initialized already.
The issue is that the initialization of the X509Token attributes only happens after the processing of the Component annotation, which is taking place once the init() method has finished, ProtocolStack.initProtocolStack() on line 795:
If we move the block of code which is calling the X509Token.setCertificate() from AUTH.init() to the beginning of AUTH.start(), the initialization and connection to the cluster are made successfully:
