[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2863: --------------------------------------- If no SSL is configured, the server responds to the client that it's not available. The ODBC client could then be configured to require SSL and hang up. That has been mentioned in the past and requires quite a bit of changes unfortunately - and may present an issue if a client is in mms mode (although I recall logic in Netty that is effectively detecting SSL initialization and reacting appropriately that we could do as well). Yes, the SSL would be beneficial to elevate, but does possibly tie into authentication via client certs (which we haven't run into just yet). So I think what you are saying is that transport would just be about port, protocol, sessioning, and worker threads and would specify a default security config. Where a security config would be a named entity specifying SSL details (or a reference to a named ssl config), the security domain, and the authentication type. It doesn't get us down to user level configurations, but that would be much more flexible than we have today. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira