[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1883:
--------------------------------
No, don't close it yet ! I was just assessing your argument and if marketing/prod mgmt thinks that we need to support SASL all the way, then fine. Is this the case ?
It's just that I wouldn't be able to do this, so if you or Tristan have time, no problem...
Your argument that the SASL tools get enhanced outside of JGroups and then we benefit from that work by upgrading the SASL lib is certainly valid.
I think you and Tristan need to discuss this (and perhaps Divya)...
> 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)
9 years, 9 months
[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz closed JGRP-1883.
-------------------------------------
Resolution: Rejected
> 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)
9 years, 9 months
[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-1883:
-------------------------------------------
I intended "ENCRYPT is basically SSL/TLS for JGroups" to me in terms of its overall function, as an encryption/authentication layer based on certificates, not in terms of how it is implemented.
I agree that my argument sounds like marketing, although in my defence, I do at least refer to committing to and adhering to a standard which may be a benefit to users who are familiar with using SASL for configuring security in non-clustering cases. You are right: there is no technical reason why we cannot say JGroups supports SASL authentication and use a separate ENCRYPT layer for integrity and confidentiality. Just as there is no technical reason why JGroups needs to support SASL at all, given that there are better, more flexible mechanisms at your disposal in the form of AUTH and ENCRYPT which are better tailored for the needs of group communication. Maybe the single advantage of SASL is that someone else (the Sasl provider) is responsible for keeping the implementation up to date.
I'll close the issue - there doesn't seem to be a lot in it.
> 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)
9 years, 9 months
[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1883:
--------------------------------
No, ENCRYPT is not TLS for JGroups. TLS is done at the transport (and requires TCP), whereas ENCRYPT works at the application level. For example, if we send a multicast to 10 cluster nodes, TLS would encrypt traffic between the sender and each recipient, whereas ENCRYPT would do the encryption once and then send a multicast with the encrypted message. This is much more efficient.
> 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)
9 years, 9 months
[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Bela Ban (JIRA)
[ 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)
9 years, 9 months
[JBoss JIRA] (JGRP-1883) Extend SASL protocol to handle Quality of Protection
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-1883?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on JGRP-1883 at 9/26/14 10:14 AM:
---------------------------------------------------------------------
That isn't what I had in mind... and also there would have to be a lot of mechanism added to the protocol to make a scheme which reuses the SaslClient and SaslServer wrap/unwrap functions work in any case. What I had in mind is adding functionality to the JGroups SASL layer so that, from the outside, it looks and is configured as a regular SASL framework, supporting the QoP features mentioned above. Internally, it would bypass the SaslClient and SaslServer wrap/uwrap functions (which is what Tristan is referring to) and use the protocols and design of ENCRYPT to enforce integrity and confidentiality in a multicast setting..
Otherwise, we will always be in the situation where we say "JGroups supports SASL" when in fact it does not; not in the sense that the QoP features of SASL are not there for use for *any* mechanism and we always have to add in an additional ENCRYPT layer to make up the shortfall on the integrity and confidentiality side. In that case, I don't see what the advantage of having a non fully-functional SASL layer is anyway. It seems like we want to move to a standard for configuring security, but not the whole way.
As for David's remark, we could consider the shortcomings that he mentions and see to what extent they apply at present to ENCRYPT. Because as far as I understand it, ENCRYPT is basically SSL/TLS for JGroups. But that's potentially a separate issue.
was (Author: rachmato):
That isn't what I had in mind... and also there would have to be a lot of mechanism added to the protocol to make a scheme which reuses the SaslClient and SaslServer wrap/unwrap functions work in any case. What I had in mind is adding functionality to the JGroups SASL layer so that, from the outside, it looks and is configured as a regular SASL framework, supporting the QoP features mentioned above. Internally, it would bypass the SaslClient and SaslServer wrap/uwrap functions (which is what Tristan is referring to) and use the protocols and design of ENCRYPT to enforce integrity and confidentiality..
Otherwise, we will always be in the situation where we say "JGroups supports SASL" when in fact it does not; not in the sense that the QoP features of SASL are not there for use for *any* mechanism and we always have to add in an additional ENCRYPT layer to make up the shortfall on the integrity and confidentiality side. In that case, I don't see what the advantage of having a non fully-functional SASL layer is anyway. It seems like we want to move to a standard for configuring security, but not the whole way.
As for David's remark, we could consider the shortcomings that he mentions and see to what extent they apply at present to ENCRYPT. Because as far as I understand it, ENCRYPT is basically SSL/TLS for JGroups. But that's potentially a separate issue.
> 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)
9 years, 9 months
[JBoss JIRA] (JBMETA-379) Missing param-name in a web.xml causes NullPointerException during deployment
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBMETA-379?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBMETA-379:
------------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1139636|https://bugzilla.redhat.com/show_bug.cgi?id=1139636] from ASSIGNED to MODIFIED
> Missing param-name in a web.xml causes NullPointerException during deployment
> ------------------------------------------------------------------------------
>
> Key: JBMETA-379
> URL: https://issues.jboss.org/browse/JBMETA-379
> Project: JBoss Metadata
> Issue Type: Bug
> Components: web
> Affects Versions: 8.0.0.Final
> Reporter: Jay Kumar SenSharma
> Assignee: Jean-Frederic Clere
> Fix For: 8.0.1.Final
>
> Attachments: ContextParamNullDemo.war
>
>
> - While deploying a WAR, If the web.xml file is used which has context <param-value> defined, However it has missing <param-name> then it causes NullPointerException as following:
> {code}
> 00:12:09,583 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0027: Starting deployment of "ContextParamNullDemo.war" (runtime-name: "ContextParamNullDemo.war")
> 00:12:09,591 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ContextParamNullDemo.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "ContextParamNullDemo.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.jboss.as.jsf.deployment.JSFVersionProcessor.deploy(JSFVersionProcessor.java:91)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> ... 5 more
> 00:12:09,598 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ContextParamNullDemo.war\".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment \"ContextParamNullDemo.war\"
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months