You should note the following items, when using the CONNECT THROUGH statement:
Granting CONNECT THROUGH to Multiple Trusted Users
A permanent or application user can be granted CONNECT THROUGH privileges through different trusted users with different roles.
Consider the following example requests, both for an application proxy user:
GRANT CONNECT THROUGH msi TO debbieg WITH ROLE msirole;
GRANT CONNECT THROUGH tadmin TO debbieg WITH ROLE tadminrole;
After these requests have been successfully submitted, both the msi and tadmin trusted users have proxy connect privileges for the application user debbieg; however, when performing the respective proxy connections, each session for debbieg is set to a different role: msirole through trusted user msi and tadminrole through trusted user tadmin.
CONNECT THROUGH and Access Logging
The system logs each GRANT CONNECT THROUGH request in the access log when logging has been enabled with BEGIN LOGGING requests such as the following:
BEGIN LOGGING ON EACH GRANT;
CONNECT THROUGH and Row-Level Security
Proxy users cannot execute SQL requests on row-level security-protected tables.
CONNECT THROUGH and Parameter Markers
Parameter markers are not supported for GRANT CONNECT THROUGH requests.
CONNECT THROUGH and User DBC
You cannot specify user DBC as either the trusted user or as a proxy user in a GRANT CONNECT THROUGH request.
CONNECT THROUGH trusted_user_name WITH TRUST_ONLY
Teradata Database allows middle tier applications to categorize an SQL request as trusted or nontrusted, which reduces the risk of users changing a proxy user by injecting SQL code or submitting SQL code via electronic whiteboarding. This implicitly assumes that applications know whether the SQL requests they submit are application-constructed or user-constructed.
When you set the WITH TRUST_ONLY option for a trusted user and a SQL request is flagged as nontrusted, Teradata Database does not permit SET QUERY_BAND requests to set a new proxy user or to remove the current proxy user.
Teradata Database enforces this through both client and server software (see Teradata Client Software Enforcement of Trusted Sessions and Teradata Server Software Enforcement of Trusted Sessions.
Middle tier applications that create their own SQL code can run in nontrusted (default) mode, enabling simple backward compatibility.
For more information, see Teradata Vantage™ - Advanced SQL Engine Security Administration, B035-1100.