[
https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin...
]
Ramesh Reddy commented on TEIID-2863:
-------------------------------------
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.
agree that the security-domain enforcement is at transport and VDB. But what I am saying
is choice of user is not there, and choice of configuring both at same time is not there.
Then user is forced to login to domain that is configured.
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?
No, JAAS name is only used in GSS. This defines the JAAS domain name space in the GSS
property file.
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?
ah, I think this is where we not communicating correctly as to how the SPENGO security
domain works. It has delegation model. Where you can define "GSS" and
"PASSWORD" based domains on it, and based on how you invoke it it chooses the
right one. Thus we do not need multiple of domains.
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