[
https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1883:
--------------------------------
OK, now I understand. But what's the point of selling SASL for authentication and
encryption while in fact the latter isn't even done via SASL mechanisms, but by
ENCRYPT code facaded by the SASL protocol ? Why can't we say that SASL (the JGroups
protocol) only supports authentication as SASL (the mechanism) isn't good enough to
provide encryption ? I don't see anything wrong in saying "JGroups supports SASL
authentication".
The above sounds like a marketing rather than technical argument to me...
*If* we decide to go ahead and do this, then we'd have to refactor the components that
ENCRYPT is made of for them to be reused in SASL. Let's avoid copy&paste here.
Tristan [~NadirX] ?
Extend SASL protocol to handle Quality of Protection
-----------------------------------------------------
Key: JGRP-1883
URL:
https://issues.jboss.org/browse/JGRP-1883
Project: JGroups
Issue Type: Feature Request
Affects Versions: 3.5
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Fix For: 3.6
SASL implementations generally provide authentication and encryption services to
communication protocols.
At present, the JGroups SASL protocol layer handles only authentication of a client
joining a group; it does not support encryption of messages (unicast and multicast)
passing through the SASL layer. This is presently handled by the separate ENCRYPT layer.
It would be nice to provide an integrated and complete solution for authentication and
encryption for JGroups based on SASL. This could be achieved by adding functionality from
ENCRYPT to the SASL layer.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)