[
https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin...
]
Steven Hawkins commented on TEIID-2863:
---------------------------------------
I thought that was the intent of this issue.
My reading of the issue is that VDBs possible down to a user level need to choose the
authentication scheme, rather than only have it configured at the transport level. So yes
the deployer needs to know the authentication scheme, but to have VDB encapsulation I
think that is somewhat required.
"authType", negotiation with JDBC is good, but IMO that
path is 100% guaranteed to end up with failure as no "jassName", so we might as
fail to begin with.
Yes if we want special handling there, then we can add it. However I was unsure if we
want to have a JAAS name mean that GSS will be used. For example will that property ever
be used for other authentication types beyond GSS?
Do you have any thoughts on the security domain handling in the JBossSessionService? Do
we need to revert back to using a list on the transport, or do we need to be more flexible
with how we look them up?
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
Attachments: auth.patch
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