Security v4

.github/workflows/action-updater.yml

@@ -13,7 +13,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v4.1.4
         with:
           # [Required] Access token with `workflow` scope.
           token: ${{ secrets.ACTION_UPDATER }}

.github/workflows/adoc-html.yml

@@ -9,8 +9,8 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v4
-    - uses: actions/setup-node@v4
+    - uses: actions/checkout@v4.1.4
+    - uses: actions/setup-node@v4.0.2
       with:
         node-version: 20
     - name: Convert adoc

.github/workflows/backport-5-0.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/backport-5-1.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/backport-5-2.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/backport-5-3.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/backport-5-4.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/backport.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/forwardport.yml

@@ -12,7 +12,7 @@ jobs:
     steps:
 
       - name: checkout
-        uses: actions/checkout@v4
+        uses: actions/checkout@v4.1.4
         with:
          fetch-depth: 0
 

.github/workflows/to-plain-html.yml

@@ -8,7 +8,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:              
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@v4.1.4
         with:
           token: ${{ secrets.TO_HTML }}      
       - name: Asciidoc to html

.github/workflows/validate.yml

@@ -13,8 +13,8 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v4
-    - uses: actions/setup-node@v4
+    - uses: actions/checkout@v4.1.4
+    - uses: actions/setup-node@v4.0.2
       with:
         node-version: 20
     - name: Check for broken internal links

docs/antora.yml

@@ -40,8 +40,8 @@ asciidoc:
     open-source-product-name: 'Community Edition'
     enterprise-product-name: 'Enterprise Edition'
     java-client-new: 'Java Client (Standalone)'
-    java-client: 'Java Client and Embedded Server'
-    url-cloud-signup: https://cloud.hazelcast.com/sign-up
+    java-client: 'Java Client and Embedded Server'    
+    url-cloud-signup: https://cloud.hazelcast.com/sign-up 
     hazelcast-cloud: Cloud
     ucn: User Code Namespaces
     ucd: User Code Deployment

docs/modules/clients/pages/java.adoc

@@ -1,11 +1,10 @@
 = Java Client
 :page-api-reference: https://docs.hazelcast.org/docs/{page-latest-supported-java-client}/javadoc
 :page-toclevels: 1
+:page-aliases: security:native-client-security.adoc
 :description: Hazelcast provides a {java-client} within the standard distribution you can start using right away, and also a lightweight {java-client-new} that is available in Beta.
 [[java-client]]
 
-// check redirects
-
 == Overview
 
 Hazelcast provides a {java-client} which you can use to connect to a Hazelcast cluster. `hazelcast-<VERSION>.jar` is bundled in the Hazelcast standard package, so just add `hazelcast-<VERSION>.jar` to your classpath and you can start using this client as if you are using the Hazelcast API.
@@ -407,7 +406,7 @@ clientConfig.setClusterName("dev");
 === Configure client security
 [blue]*Hazelcast {enterprise-product-name}* 
 
-You can define control mechanisms for clients to control authentication and authorisation. For more information, see xref:security:native-client-security.adoc[].
+You can define control mechanisms for clients to control authentication and authorisation. For more information, see xref:security:client-authorization.adoc[].
 
 You can provide the Java client with an identity for cluster authentication. The identity of the connecting client is defined on the client side.
 Usually, there are no security realms on the clients; only the identity defined in the security configuration.
@@ -1296,7 +1295,7 @@ You can configure the cluster routing mode to suit your requirements, as describ
 The following examples show the configuration for each cluster routing mode. 
 
 NOTE: If your clients want to use temporary permissions defined in a member, see 
-xref:security:native-client-security.adoc#handling-permissions-when-a-new-member-joins[Handling Permissions].
+xref:security:client-authorization.adoc#handling-permissions-when-a-new-member-joins[Handling Permissions].
 
 **Client ALL_MEMBERS routing**
 

docs/modules/clients/pages/memcache.adoc

@@ -1,11 +1,12 @@
 = Memcache Client
 
+NOTE: Hazelcast Memcache Client only supports ASCII protocol. Binary Protocol is not supported.
+
 A Memcache client written in any language can talk directly to a Hazelcast cluster.
 No additional configuration is required.
 
-NOTE: Hazelcast Memcache Client only supports ASCII protocol. Binary Protocol is not supported.
-
-To be able to use a Memcache client, you must enable the Memcache client request listener service using either one of the following configuration options:
+To be able to use a Memcache client, you must enable
+the Memcache client request listener service using either one of the following configuration options:
 
 1 - Using the `network` configuration element:
 

docs/modules/cluster-performance/pages/performance-tips.adoc

@@ -596,37 +596,26 @@ Here are the essential tips:
 * But it needs to be considered from the outset, as it affects architecture, performance and coding
 * Security can then be added before go-live without rework
 
-TLS/SSL can have a significant impact on performance. There are a few ways to
-increase the performance.
-
-The first thing that can be done is making sure that AES intrinsics are used.
-Modern CPUs (2010 or newer Westmere) have hardware support for AES encryption/decryption
-and the JIT automatically makes use of these AES intrinsics. They can also be
-explicitly enabled using `-XX:+UseAES -XX:+UseAESIntrinsics`,
-or disabled using `-XX:-UseAES -XX:-UseAESIntrinsics`.
-
-A lot of encryption algorithms make use of padding because they encrypt/decrypt in
-fixed sized blocks. If there is no enough data
-for a block, the algorithm relies on random number generation to pad. Under Linux,
-the JVM automatically makes use of `/dev/random` for
-the generation of random numbers. `/dev/random` relies on entropy to be able to
+=== TLS Tuning
+
+You can improve TLS performance in a number of ways.
+
+Check if `securerandom.source` is configured to `/dev/urandom` in your
+`<JAVA_HOME>/conf/security/java.security` file.
+If there is `/dev/random` instead, it might block on operations which
+require random data generation.
+The `/dev/random` relies on entropy to be able to
 generate random numbers. However, if this entropy is
 insufficient to keep up with the rate requiring random numbers, it can slow down
 the encryption/decryption since `/dev/random` will
-block; it could block for minutes waiting for sufficient entropy . This can be fixed
-by setting the `-Djava.security.egd=file:/dev/./urandom` system property.
+block. This can be fixed
+by setting the `-Djava.security.egd=file:/dev/urandom` system property.
 For a more permanent solution, modify the
-`<JAVA_HOME>/jre/lib/security/java.security` file, look for the
-`securerandom.source=/dev/urandom` and change it
-to `securerandom.source=file:/dev/./urandom`. Switching to `/dev/urandom` could
-be controversial because `/dev/urandom` will not
-block if there is a shortage of entropy and the returned random values could
-theoretically be vulnerable to a cryptographic attack.
-If this is a concern in your application, use `/dev/random` instead.
-
-Hazelcast's Java smart client automatically makes use of extra I/O threads
-for encryption/decryption and this have a significant impact on the performance.
-This can be changed using the `hazelcast.client.io.input.thread.count` and
+`<JAVA_HOME>/conf/security/java.security` file and change directly the `securerandom.source` property value.
+
+Clients using Hazelcast's Java `ALL_MEMBERS` and `MULTI_MEMBER` cluster routing modes automatically make use of extra I/O threads
+for encryption/decryption and this has a significant impact on the performance.
+The number of threads used can be changed using the `hazelcast.client.io.input.thread.count` and
 `hazelcast.client.io.output.thread.count` client system properties.
 By default it is 1 input thread and 1 output thread. If TLS/SSL is enabled,
 it defaults to 3 input threads and 3 output threads.