AUTH and Friends

[Alan McSherry]

Hi, 

Surprisingly I could only find one conversation involving authentication in this group, apologies if I'm missing a trick here. (I'm very new to JGroups)

I've read that Bela doesn't recommend using the AUTH implementations so my first question is, is the AUTH mechanism in general flawed or could I extend AuthToken myself and expect a good result? 

Specifically and simplifying a bit - I want to check the join message (and probably some other messages) has been signed correctly by one of a set of public keys. 

Secondly, it seems that the JGroups discovery part is really "at home" in an intranet and not built for could-be-anywhere internet nodes forming a group - is that fair? If not, how would you recommend to set up a internet based dynamic JGroup?

Thanks!

[Bela Ban]

On 18.10.23 18:21, 'Alan McSherry' via jgroups-raft wrote:
> Hi,
>
> Surprisingly I could only find one conversation involving authentication
> in this group, apologies if I'm missing a trick here. (I'm very new to
> JGroups)
>
> I've read that Bela doesn't recommend using the AUTH implementations so
> my first question is, is the AUTH mechanism in general flawed or could I
> extend AuthToken myself and expect a good result?

Read http://www.jgroups.org/manual5/index.html#AUTH (section 'Problems
with AUTH'). The one-way hashed token was removed, but other uses such
as a range of allowed IP addresses still makes sense IMO. My
recommendation would be to do this in combination with (e.g.)
ASYM_ENCRYPT / SSL_KEY_EXCHANGE or SYM_ENCRYPT.

> Specifically and simplifying a bit - I want to check the join message
> (and probably some other messages) has been signed correctly by one of a
> set of public keys.

Yes, this is feasible, you could start by copying X509Token and making
changes. However, *if* you already use the combo of ASYM_ENCRYPT /
SSL_KEY_EXCHANGE, then we've already validated the cert (in the latter
protocol).

Note - as an alternative - that you could also use TLS
(http://belaban.blogspot.com/2023/04/support-for-tlsssl-in-tcp.html) to
use SSLSockets that encrypt your entire traffic.

> Secondly, it seems that the JGroups discovery part is really "at home"
> in an intranet and not built for could-be-anywhere internet nodes
> forming a group - is that fair?

No! There are a plethora of discovery protocols
(http://www.jgroups.org/manual5/index.html#DiscoveryProtocols) to
accommodate many requirements / network environments.

> If not, how would you recommend to set

> up a internet based dynamic JGroups?

The following discovery protocols come to mind:

* TCPPING: static list, but if you list some members out of which at
least 1 member is always running, it would work. To cache discovery
results, you could use PDC (disk cache)

* FILE_PING: if you have a shared file system, e.g. NFS, a common
directory allows all members to discover each other

* JDBC_PING: shared DB

* Cloud / containers:
* KUBE_PING: Kubernetes / Openshift
* NATIVE_S3_PING: AWS
* GOOGLE_PING: GCP
* AZURE_PING: Azure
* DNS_PING: Kubernetes/Openshift

* TCPGOSSIP: discovery via one or more GossipRouter processes

Hope this helps,
Cheers


> Thanks!
>
> --
> You received this message because you are subscribed to the Google
> Groups "jgroups-raft" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jgroups-raft...@googlegroups.com
> <mailto:jgroups-raft...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jgroups-raft/bed7c103-73c5-4882-8a31-e91f649c4cfcn%40googlegroups.com <https://groups.google.com/d/msgid/jgroups-raft/bed7c103-73c5-4882-8a31-e91f649c4cfcn%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Bela Ban | http://www.jgroups.org