[
https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
Ok, the SSL is over individual connection rather than whole transport. The follow on
question is, if the transport is not configured with any SSL certificates how does
SSLEngine work, seems like in the code is reading the SSLConfig from transport settings?
or does it use anonymous SSL in that case?
Either way, we would need to devise similar functionality for JDBC too, so that we would
not need need multiple sockets. Then, I also propose that we pull the "auth"
& "ssl" specific configuration in the transport to Teiid system level with a
defined name, then we can just reference it in VDB(s) or Transport(s) as enforcing
mechanism. Otherwise all the SSL, auth properties can get little hairy everywhere. And
also VDB does not get commited to one way of doing security, but will depend upon
environment (DEV/TEST/PROD) configurations, like we do for data sources.
Teiid concept of transport is not living up to our original intentions with what users are
really looking for -:(
Allow both gssapi and username/password authentication on the same
transport
----------------------------------------------------------------------------
Key: TEIID-2863
URL:
https://issues.jboss.org/browse/TEIID-2863
Project: Teiid
Issue Type: Enhancement
Components: Server
Reporter: Steven Hawkins
Assignee: Steven Hawkins
With GSSAPI support enabled, username/password support on the same transport is
effectively disabled. JDBC/ODBC should ideally support both on the same transport.
--
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