4:05 p.m.
The docs state that "By default there's nothing to prevent unauthorized
nodes from joining the cluster and sending potentially malicious messages
to the cluster." (
http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering....
)
Is this still the case if the jgroups stack in Wildfly has implemented the
AUTH protocol? For example, the Openshift Wildfly config looks something
like this:
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp">
<property
name="external_addr">${env.OPENSHIFT_GEAR_DNS}</property>
<property
name="external_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PROXY_PORT}</property>
<property
name="bind_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PORT}</property>
<property
name="bind_addr">${env.OPENSHIFT_WILDFLY_IP}</property>
<property name="defer_client_bind_addr">true</property>
</transport>
<protocol type="TCPPING">
<property name="timeout">30000</property>
<property
name="initial_hosts">${env.OPENSHIFT_WILDFLY_CLUSTER}</property>
<property name="port_range">0</property>
<property name="num_initial_members">1</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="AUTH">
<property
name="auth_class">org.jgroups.auth.MD5Token</property>
<property name="token_hash">SHA</property>
<property
name="auth_value">${env.OPENSHIFT_SECRET_TOKEN}</property>
</protocol>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<!--protocol type="pbcast.STATE_TRANSFER"/>
<protocol type="pbcast.FLUSH"/-->
</stack>
--
*Matthew Casperson*
*Senior Front End Developer*
Technology, Space & Distribution
Auto & General Holdings Pty Ltd
P: 07) 3377 8751 (Direct: 3377 8751)
F: 07) 3377 8833
--
This email is sent by Auto & General Insurance Company Ltd, Auto & General
Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto
& General) and is for the intended addressee.
The views expressed in this email and attachments (email) reflect the views of the stated
author but may not reflect views of Auto & General. This email is confidential and
subject to copyright.
It may be privileged. If you are not the intended addressee, confidentiality and privilege
have not been waived and any use, interference with, or disclosure of this email is
unauthorised.
If you are not the intended addressee please immediately notify the sender and then delete
the email. Auto & General does not warrant that this email is error or virus free.
1:52 a.m.
I believe enabling auth is sufficient, but I'm not 100% sure. I've sent an
email to JGroups mailing list to confirm and I'll let you know.
On 11 November 2015 at 23:05, Matthew Casperson <
matthew.casperson(a)autogeneral.com.au> wrote:
The docs state that "By default there's nothing to prevent
unauthorized
nodes from joining the cluster and sending potentially malicious messages
to the cluster." (
http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering....
)
Is this still the case if the jgroups stack in Wildfly has implemented the
AUTH protocol? For example, the Openshift Wildfly config looks something
like this:
<stack name="tcp">
<transport type="TCP" socket-binding="jgroups-tcp">
<property
name="external_addr">${env.OPENSHIFT_GEAR_DNS}</property>
<property
name="external_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PROXY_PORT}</property>
<property
name="bind_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PORT}</property>
<property
name="bind_addr">${env.OPENSHIFT_WILDFLY_IP}</property>
<property
name="defer_client_bind_addr">true</property>
</transport>
<protocol type="TCPPING">
<property name="timeout">30000</property>
<property
name="initial_hosts">${env.OPENSHIFT_WILDFLY_CLUSTER}</property>
<property name="port_range">0</property>
<property name="num_initial_members">1</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="AUTH">
<property
name="auth_class">org.jgroups.auth.MD5Token</property>
<property name="token_hash">SHA</property>
<property
name="auth_value">${env.OPENSHIFT_SECRET_TOKEN}</property>
</protocol>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<!--protocol type="pbcast.STATE_TRANSFER"/>
<protocol type="pbcast.FLUSH"/-->
</stack>
--
*Matthew Casperson*
*Senior Front End Developer*
Technology, Space & Distribution
Auto & General Holdings Pty Ltd
P: 07) 3377 8751 (Direct: 3377 8751)
F: 07) 3377 8833
This email is sent by Auto & General Insurance Company Ltd, Auto & General
Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto
& General) and is for the intended addressee.
The views expressed in this email and attachments (email) reflect the views of the stated
author but may not reflect views of Auto & General. This email is confidential and
subject to copyright.
It may be privileged. If you are not the intended addressee, confidentiality and
privilege have not been waived and any use, interference with, or disclosure of this email
is unauthorised.
If you are not the intended addressee please immediately notify the sender and then
delete the email. Auto & General does not warrant that this email is error or virus
free.
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:37 a.m.
AUTH in JGroups only authenticates nodes that join a group. Nodes will
discard messages that are not sent by a member of the group. However,
someone could in theory eavesdrop on the messages and pick up the id
assigned to a member of the group, they could then send a
message masquerading as a member of the group.
We don't send any sensitive information through the cluster so even if
someone was able to read messages sent to the cluster they would not be
able to obtain anything valuable. Further there's very little a malicious
node could do by sending fake messages to the cluster. With regards to
realms, clients and users they would only be able to send invalidation
messages, forcing nodes to re-load the data from the database. For sessions
they could in theory create new user sessions, but these would not have any
use as cookies and tokens are signed by the realms private key, so the fake
sessions wouldn't have any use.
In summary enabling auth should be sufficient and encryption should not be
required as long as you use the default clustering setup
(invalidation-cache for realm, users and clients).
On 12 November 2015 at 08:52, Stian Thorgersen <sthorger(a)redhat.com> wrote:
I believe enabling auth is sufficient, but I'm not 100% sure.
I've sent an
email to JGroups mailing list to confirm and I'll let you know.
On 11 November 2015 at 23:05, Matthew Casperson <
matthew.casperson(a)autogeneral.com.au> wrote:
> The docs state that "By default there's nothing to prevent unauthorized
> nodes from joining the cluster and sending potentially malicious messages
> to the cluster." (
> http://keycloak.github.io/docs/userguide/keycloak-server/html/clustering....
> )
>
> Is this still the case if the jgroups stack in Wildfly has implemented
> the AUTH protocol? For example, the Openshift Wildfly config looks
> something like this:
>
> <stack name="tcp">
> <transport type="TCP"
socket-binding="jgroups-tcp">
> <property
name="external_addr">${env.OPENSHIFT_GEAR_DNS}</property>
> <property
name="external_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PROXY_PORT}</property>
> <property
name="bind_port">${env.OPENSHIFT_WILDFLY_CLUSTER_PORT}</property>
> <property
name="bind_addr">${env.OPENSHIFT_WILDFLY_IP}</property>
> <property
name="defer_client_bind_addr">true</property>
> </transport>
> <protocol type="TCPPING">
> <property name="timeout">30000</property>
> <property
name="initial_hosts">${env.OPENSHIFT_WILDFLY_CLUSTER}</property>
> <property name="port_range">0</property>
> <property name="num_initial_members">1</property>
> </protocol>
> <protocol type="MERGE2"/>
> <protocol type="FD"/>
> <protocol type="VERIFY_SUSPECT"/>
> <protocol type="BARRIER"/>
> <protocol type="pbcast.NAKACK"/>
> <protocol type="UNICAST2"/>
> <protocol type="pbcast.STABLE"/>
> <protocol type="AUTH">
> <property
name="auth_class">org.jgroups.auth.MD5Token</property>
> <property name="token_hash">SHA</property>
> <property
name="auth_value">${env.OPENSHIFT_SECRET_TOKEN}</property>
> </protocol>
> <protocol type="pbcast.GMS"/>
> <protocol type="UFC"/>
> <protocol type="MFC"/>
> <protocol type="FRAG2"/>
> <!--protocol type="pbcast.STATE_TRANSFER"/>
> <protocol type="pbcast.FLUSH"/-->
> </stack>
>
>
>
> --
> *Matthew Casperson*
> *Senior Front End Developer*
> Technology, Space & Distribution
> Auto & General Holdings Pty Ltd
> P: 07) 3377 8751 (Direct: 3377 8751)
> F: 07) 3377 8833
>
>
>
> This email is sent by Auto & General Insurance Company Ltd, Auto & General
Services Pty Ltd, Auto & General Holdings Pty Ltd or a related body corporate (Auto
& General) and is for the intended addressee.
> The views expressed in this email and attachments (email) reflect the views of the
stated author but may not reflect views of Auto & General. This email is confidential
and subject to copyright.
> It may be privileged. If you are not the intended addressee, confidentiality and
privilege have not been waived and any use, interference with, or disclosure of this email
is unauthorised.
> If you are not the intended addressee please immediately notify the sender and then
delete the email. Auto & General does not warrant that this email is error or virus
free.
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
3822
days inactive
3823
days old
2 comments
2 participants
participants (2)
-
Matthew Casperson -
Stian Thorgersen