CREATE/REPLACE AUTHORIZATION | Teradata Connector | Teradata Fabric - Usage Notes (CREATE/REPLACE AUTHORIZATION) - Teradata Fabric

Teradata® Fabric - Installation and User Guide - 3.11
Product
Teradata Fabric
Release Number
3.11
Published
August 2026
ft:locale
en-US
ft:lastEdition
2026-08-15
dita:mapPath
svw1780362788070.ditamap
dita:ditavalPath
ezw1784752870623.ditaval
dita:id
lxg1591800469257
  • An authorization is required only when using an external security system such as Kerberos for authentication on the target platform of the foreign server.
  • You must use either INVOKER TRUSTED or DEFINER TRUSTED when authentication on Hadoop is performed by an external security system such as Kerberos.
  • Use INVOKER TRUSTED when creating a one-to-one mapping between the Teradata user and the user on the target platform of the foreign server. For example, using the same user name for Teradata and Kerberos.
  • Use DEFINER TRUSTED when creating a many-to-one mapping between Teradata users and a user on the target platform of the foreign server. For example, when you want multiple Teradata users to make requests to the foreign server using one Kerberos account on the target platform.
  • Set Username and Password connector properties in the Teradata Fabric portlet. These are used for connector diagnostic checks and for end-to-end queries if they were not provided by the initiator in the authorization object.
  • When creating an authorization for another user using INVOKER TRUSTED, user_dbname must be specified. Specify the username associated with the session user sending requests to the foreign server. If you fail to specify user_dbname, the authorization is stored in your user database.
  • The authorization does not take up space in the database storing it.
  • If your credentials change on the target platform of the foreign server, you must remember to replace the credentials in your authorization object. If you fail to update the invalid information, an error message displays the next time you try to reference the foreign server object.
  • When dropping an authorization object, it may be used by multiple foreign server objects. Either drop the foreign server objects or alter the objects so they specify a valid authorization object. If you fail to update the invalid information, an error message displays the next time you try to reference the foreign server object.