[ https://issues.jboss.org/browse/TEIID-5780?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-5780: --------------------------------------- There would be service signing certificate created both for the teiid pg service, and one create for the pg database. It would one for the Teiid pg service as shown in https://github.com/teiid/teiid-openshift-examples/blob/master/keycloak/ke... Note that the deployment config converts the service signing certificate to a jks file: https://github.com/teiid/teiid-openshift-examples/blob/master/keycloak/sr... to use with a Teiid transport. This needs to occur for the pg instance as well. It will have to have a signing certificate created, which an init container would turn into the the appropriate formats (pem and der) for consumption by the pg fdw connection to present to Teiid as the client certificate. Each side will also need additional changes for another init container that creates or adds to a trust store on each side the public key from the other side. At the end of the day that means that the teiid pg transport will support mutual authentication such that connections from the pg server are trusted. On top of that there is the additional configuration on the Teiid session service to set a specific certificate principal as the admin account. This would need to match whatever openshift populates for the service signing certificate created for the pg database service. It is primarily so that a pg client to Teiid can assume an "admin" role for materialization. You could extrapolate this is several ways to make it a more general mechanism. Essentially we need the connection coming in from pg to read Teiid to be a super user. At a minimum it has to see all tables (which marking the dqpworkcontext as admin does). It will probably need to be granted all roles as well - as it needs to be able to directly read from any view that is marked as materialized, which is not required of the normal materialization logic because it performs loads via procedures. The other approach would be to have the user designate or create an admin user in the realm used with each vdb, and the provide the credentials if materialization is being used. A thousand words is worth one picture right? -- This message was sent by Atlassian Jira (v7.12.1#712002)