2:25 p.m.
[
https://issues.jboss.org/browse/TEIID-2260?page=com.atlassian.jira.plugin...
]
Ramesh Reddy resolved TEIID-2260.
---------------------------------
Resolution: Done
In the 8.x, each transport can be configured with their own security domain. The ODBC
layer, underneath uses Embedded transport which by default does not have any security
because it is always considered in VM. However, when ODBC used embedded it ignored the
security domain configured on the ODBC and followed the embedded rules, which was wrong.
Fixed by removing the use of "embedded" transport underneath the ODBC, and
providing a way to directly make connection to server by registering a overridden
connection profile that can be only used by ODBC layer.
Teiid 8.X ODBC port does not follow security settings
-----------------------------------------------------
Key: TEIID-2260
URL: https://issues.jboss.org/browse/TEIID-2260
Project: Teiid
Issue Type: Bug
Components: ODBC
Affects Versions: 8.2
Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
java version "1.7.0_05-icedtea"
OpenJDK Runtime Environment (rhel-2.2.1.el6_3.3-x86_64)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)
jbossas-standalone-7.1.2-8.Final_redhat_1.ep6.el6.noarch (JBoss EAP 6)
Reporter: Graeme Gillies
Assignee: Ramesh Reddy
Priority: Blocker
Fix For: 8.2
Hi,
We have the following configuration setup in our teiid 8.2 aplha 2 environment running on
eap6
{noformat}
<transport name="jdbc"
socket-binding="teiid-jdbc">
<authentication security-domain="REDHAT.COM"/>
<ssl mode="enabled" ssl-protocol="SSLv3"
keymanagement-algorithm="SunX509">
<keystore name="/etc/jbossas/standalone/jboss.keystore"
password="changeit"/>
</ssl>
</transport>
<transport name="odbc" socket-binding="teiid-odbc"
protocol="pg">
<authentication security-domain="REDHAT.COM"/>
<ssl mode="enabled" ssl-protocol="SSLv3"
keymanagement-algorithm="SunX509">
<keystore name="/etc/jbossas/standalone/jboss.keystore"
password="changeit"/>
</ssl>
</transport>
{noformat}
With out security configuration looking like
{noformat}
<security-domain name="host"
cache-type="default">
<authentication>
<login-module code="Kerberos"
flag="required">
<module-option name="storeKey"
value="true"/>
<module-option name="useKeyTab"
value="true"/>
<module-option name="principal"
value="HTTP/REMOVED_HOSTNAME(a)REDHAT.COM"/>
<module-option name="keyTab"
value="/etc/jbossas/standalone/jboss.keytab"/>
<module-option name="doNotPrompt"
value="true"/>
<module-option name="debug"
value="true"/>
</login-module>
</authentication>
</security-domain>
<security-domain name="fallback"
cache-type="default">
<authentication>
<login-module code="Kerberos"
flag="required">
<module-option name="useTicketCache"
value="true"/>
<module-option name="useKeyTab"
value="false"/>
<module-option name="doNotPrompt"
value="true"/>
<module-option name="debug"
value="true"/>
</login-module>
</authentication>
</security-domain>
<security-domain name="REDHAT.COM"
cache-type="default">
<authentication>
<login-module code="SPNEGO"
flag="requisite">
<module-option name="password-stacking"
value="useFirstPass"/>
<module-option name="serverSecurityDomain"
value="host"/>
<module-option name="removeRealmFromPrincipal"
value="true"/>
<module-option name="usernamePasswordDomain"
value="fallback"/>
</login-module>
</authentication>
</security-domain>
{noformat}
And the security seems to work as expected for the JDBC connection, but when we try to
connect via ODBC to port 35432 it simply allows us to connect regardless of any
username/password combination we use. We tried even switching back to just basic
username/password login module (against flat files) with same results.
--
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