Setup steps:
1. Deploy a Teiid datasource to a JBoss container and ensure that <xa-datasource-property name="PassthroughAuthentication">true</xa-datasource-property> is present in the datasource definition.
2. Constrain access to a schema element of the Virtual Database for a particular role. For instance, create a VDB Data Role which denies Read access to a given column of a table in the virtual database for some role (say data2Role).
3. Create another VDB Data Role definition which allows Read access to said column for some role (say data1Role).
4. Change the Security Realm used by Teiid ("securityDomains" property of SessionService in teiid-jboss-beans.xml) to refer to an installed LoginModule and ensure that security realm defines roles used in the mapping above.
5. Deploy the VDB to JBoss.
6. Develop a JSP page which will: a) lookup the Teiid datasource from JNDI, b) call getConnection() on the datasource, c) execute a statement which includes reading from the restricted column mentioned above (e.g. select * from thatTable). Configure the JSP's web security constraints (web.xml) to require the caller be authenticated in order to access the page. And configured to be authenticated by the same LoginModule that was configured in step-4 above (use jboss-web.xml).
7. Deploy the JSP to the same JBoss instance as hosting the Teiid datasource.

Test steps:
1. Access the JSP as a user which is in the data1Role. This caller's identity should permit them to access the security constrained column. There should be no errors raised and the results of that column should be returned by Teiid.
2. Now invalidate the JSP's HTTP Session so that accessing the JSP requires the caller to authenticate again. This time, authenticate as a user which has the data2Role. This call should have Teiid return a JDBC connection which is associated with this new identity and thus should not be granted access to data in the restricted column. This access attempt should cause Teiid to raise an exception. What is observed however is that the SQL statement is processed without error indicating that the connection is still associated with the original identity and not switched as it should have been to the new caller identity.
3. You can confirm that this isn't caused by JBoss not switching identities on the subject by the following procedure. Touch the Teiid datasource definition file ('teiid-ds.xml') to cause JBoss and Teiid to unload and then reload the datasource (i.e. clear out the connection pool). Then fetch the JSP page again. Since you are still authenticated with the web container the request from the JSP to Teiid will be as the second identity, but this time Teiid will create a new connection (as there are none in the pool) and will thus recognize the caller's identity and use it for authorization decisions and thus will raise an SQL Exception because the caller doesn't have Read permission on the column.

A possible workaround would be to avoid keeping connections around after they are closed: i.e. avoid pooling connections and have them truly created new on every getConnection(). I've not been able to disable the connection pool: setting max pool size to zero causes a hang. Thus, no known workarounds exist.