[teiid-issues] [JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport

[Steven Hawkins (JIRA)]

    [ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12948771#comment-12948771 ] 

Steven Hawkins commented on TEIID-2863:
---------------------------------------

> 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?

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.

> Either way, we would need to devise similar functionality for JDBC too, so that we would not need need multiple sockets.

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).

> 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.

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).

> 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.

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. 

                
> 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