- Optional name of the location where the authorization is to be stored.
- The default location that is used changes based on whether DEFINER or INVOKER is specified. The following rules apply to specifying DEFINER or INVOKER:
- If you specify DEFINER, the database or user you specify must be the containing database or user for the foreign server, UDF, table UDF, method, or external SQL procedure. If no location is specified, the authorization is created in the database that contains the foreign server objects (TD_SERVER_DB).
- If you specify INVOKER, the database_name or user_dbname you specify must be associated with the session user who will be sending requests to the foreign server. If no location is specified, the authorization is placed in the user database of the creator of the authorization.
- Name for the authorization object. This name must be unique within the database in which it is stored.
- If you specify INVOKER TRUSTED, or if you specify TRUSTED alone, Teradata creates the authorization object in the database of the user who creates the object. This syntax makes the authorization available only to those with privilege to the user database.
- If you specify DEFINER TRUSTED or DEFINER DEFAULT TRUSTED, then Teradata creates the authorization object in the database that contains the object that is using the authorization; for a foreign server this is the TD_SERVER_DB database. This syntax makes the authorization globally available.
- A keyword used to specify that the credentials are to be encrypted and stored as database objects.
- When using an authorization object, you must use the TRUSTED security type for the Teradata QueryGrid Teradata connector.
- You cannot use TRUSTED authorizations in CREATE or REPLACE UDF or XSP statements.
- The name of the credential on the remote platform to be used by the foreign server.
The user name for the authorization object can consist of a user name alone or a user name and the name of the Kerberos realm. When only the user name is specified, the default realm specified in the krb5.conf file is used for kinit.
If you include the Kerberos realm name, then the default realm is ignored and the realm that you specify in the authorization object is used for kinit. You should include a Kerberos realm name if you have one of the following situations:
If used with the name of the Kerberos realm, the user_name portion cannot also contain an @ sign.
- You want users to be able to connect to multiple Kerberized clusters, each from a different realm, from the same Teradata system.
- You want users to be able to connect to a Kerberized cluster where the authentication realm is different from the service realm.
- The password for the credential on the remote platform to be used by the foreign server.
- All existing rules for CREATE AUTHORIZATION and REPLACE AUTHORIZATION apply.
- For more information about using CREATE AUTHORIZATION and REPLACE AUTHORIZATION, see Teradata® Database SQL Data Definition Language - Syntax and Examples, B035-1144.