[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ] Ondrej Lukas commented on WFCORE-2615: -------------------------------------- [~dmlloyd] Thanks for clarification. We still think that optimal solution is provide this feature as white-list. Other solutions can lead to confusions and also can mean more effort. In case we decide to leave the current behavior in application server then we should consider renaming allow-sasl-mechanisms to something more descriptive. Instead of meaning "allow mechanisms" it should mean something like "try this mechanism even if configuration does not include all needed attributes for this mechanism". Moreover if current behavior will be part of application server then we have to provide more clear documentation in management model (for JBoss CLI read operation) and XSD. I agree with: _"... the lack of an allowed set seems to mean all-allowed to some people and none-allowed to other people ..."_ but in case when "allow-all" is provided and "forbid-all" does not exist then I think it indirectly implies that lack of allowed set means none-allowed (otherwise "allow-all" is useless). We should consider whether "forbid-all" would be useful - in combination with "allow-sasl-mechanisms" it provides simple way how to enable only specific SASL mechanism. I understand that choosing of mechanism can be improved and there are not boundaries "how" to improve it (e.g. as you said, exclude mechanisms that use certain crypto primitives can be this improvement), but I think then providing "forbid-all" could really help during configuration. [~dlofthouse] could you please share your point of view on this issue? -- This message was sent by Atlassian JIRA (v7.2.3#72005)