[
https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-2863:
---------------------------------------
Correct me if I'm wrong, but aren't we fairly close with our current structure.
For example if we remove the LogonImpl.logon check of the authentication type and allow
the JDBC client to determine on its own whether to make a gssapi login - won't that
allow for gss and password authentications on the same transport (with logically similar
changes on the ODBC side)?
I think we are also now, after the change to allow the vdb to declare a security domain,
effectively moving toward treating the security domains setting on a transport to be
interpreted as the default security domain (singular). We could do something similar with
the idea of what the kerberos security domain is, that is declaring it in the vdb.xml. Or
couldn't we just assume that the kerberos loginmodule is stacked in the same security
domain?
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