CREATE TRUSTED CONTEXT statement

Use the CREATE TRUSTED CONTEXT statement to define a newtrusted-context object. This statement is an extension to the ANSI/ISO standard for the SQL language.

You must hold the database security administrator (DBSECADM) role to run this statement.

Syntax


>>-CREATE TRUSTED CONTEXT--context------------------------------>

>--+-USER--------------------------------------+--user---------->
   '-BASED UPON CONNECTION USING SYSTEM AUTHID-'         

   .------------------------------------------------------------.   
   |                        .-,--------------------------.      |   
   V    (1)                 V                            |      |   
>----+-------ATTRIBUTES--(------ADDRESS--'--address--'---+--)-+-+-><
     |                     .-,--------------------------.     |     
     |  (1)                V                            |     |     
     +-------WITH USE FOR----| Authorized User Clause |-+-----+     
     |  (1).-NO DEFAULT ROLE----.                             |     
     +-----+--------------------+-----------------------------+     
     |     '-DEFAULT ROLE--role-'                             |     
     |  (1).-DISABLE-.                                        |     
     '-----+---------+----------------------------------------'     
           '-ENABLE--'                                              

Authorized User Clause

                             .-WITHOUT AUTHENTICATION-.   
|--+-user--+------------+-+--+------------------------+---------|
   |       '-ROLE--role-' |  '-WITH AUTHENTICATION----'   
   '-PUBLIC---------------'

Notes:

Use path no more than once

Element	Description	Restrictions	Syntax
address	Communication address of the client connection to the database server	Must be unique among communication addresses of clients for this trusted-context object. For additional address restrictions, see ADDRESS attributes below.	Quoted String
context	Name declared here for the trusted-context object	Must be unique among the names of trusted-context objects of this database server instance, and cannot begin with the characters `SYS`	Identifier
role	An existing user-defined or built-in role	Must exist in the database, and must be unique among attributes of this trusted-context object	Owner name
user	Authorization identifier of a user	Must be a valid authorization identifier. Cannot be longer than 32 bytes. Must not be the authorization ID of the user who issues this statement. Must not be specified more than once in the WITH USE FOR clause.	Owner name

Usage

The CREATE TRUSTED CONTEXT statement is used to create trusted-context objects, which can allow users to have trusted connections. Within the CREATE TRUSTED CONTEXT STATEMENT, each ATTRIBUTES, DEFAULT ROLE, ENABLE, and WITH USE clause can be specified no more than once, and each attribute name and corresponding value must be unique.

USER clause

The USER clause specifies the system authorization ID that can establish the context created in this SQL statement. The USER clause in this statement is valid for the Informix® database server only, where the USER keyword is equivalent to the keywords BASED UPON CONNECTION USING SYSTEM AUTHID, which are required in the CREATE TRUSTED CONTEXT statement of IBM® DB2®. Those six keywords can specify the system authorization ID on both Informix and IBM DB2 database servers, but only Informix supports the USER keyword as their synonym.

ADDRESS attributes

The ATTRIBUTES clause can specify one or more communication addresses for connections to the database server on which the trusted-context object is defined. The following restrictions apply to communication addresses that the ALTER TRUSTED CONTEXT or the CREATE TRUSTED CONTEXT statements reference:

Each must be unique among communication addresses of clients for this trusted-context object.
Each must conform to the TCP/IP protocol.
Each must be an IPv4 address, an IPv6 address, or a secure domain name.
An IPv4 address or IPv6 address must be a real host address (not a local host), and must not contain leading blank spaces.
An IPv6 address, in addition, must not be an IPv4-mapped IPv6 address.
A secure domain name must not be a Dynamic Host Configuration Protocol (DHCP) address.

If an address value is the name of a secure domain, that name is converted to an IP address by the domain-name server, where a resulting IPv4 or IPv6 address is determined. When a domain name is converted to an IP address, the result of this conversion might be a set of one or more IP addresses. In this case, the database server interprets an incoming connection request as matching the ADDRESS attribute of a trusted-context object if the IP address from which the connection originates matches any of the IP addresses to which the domain name was converted.

The ADDRESS attribute can be specified multiple times, but each address pair must be unique for the set of attributes.

Attention:

If you have an existing application that includes the ENCRYPTION or WITH ENCRYPTION options in the ATTRIBUTES clause, you can leave them without the database server issuing an SQL error. Except for WITH ENCRYPTION 'NONE' and ENCRYPTION 'NONE', however, these encryption options of the CREATE TRUSTED CONTEXT statement are not supported for Informix database servers.

WITH USE FOR clause

The WITH USE FOR clause specifies that the trusted connection can be used by the specified authorization identifier. The same user name cannot appear more than once in this clause, which allows access by both the list of specified users and by PUBLIC.

For example, assume that a trusted-context object is defined that allows access by both PUBLIC WITH AUTHENTICATION and joe WITHOUT AUTHENTICATION. If the trusted-context object is used by joe, authentication is not required. If the trusted-context object is used by george, however, who has access only as a member of PUBLIC, authentication is required.

The WITH AUTHENTICATION attribute specifies that switching the current user on a trusted connection based on this trusted-context object to this user requires authentication. The WITHOUT AUTHENTICATION attribute specifies that switching the current user does not require authentication. The specifications for a user override the specifications for PUBLIC.

These attributes also affect whether authentication is required during client sessions with ODBC, JDBC, or ESQL/C connections, in which the SET SESSION AUTHORIZATION statement attempts to switch to a different user ID after a trusted connection has been established. The same attributes similarly affect whether authentication is required when switching the user during client sessions on trusted connections that HCL Data Server Driver for JDBC and SQLJ established, and on trusted connections established by HCL Data Server Provider for .NET.

DEFAULT ROLE attributes

A ROLE object specifies the user's role (and privileges) when using a trusted connection. A DEFAULT ROLE identifies a role that exists at the current server, and is used when a user does not have a user-specific role defined as part of the definition of the trusted-context object. The NO DEFAULT ROLE attribute will specify that the trusted-context object does not have a default role. The default is NO DEFAULT ROLE. The role explicitly specified for the user overrides any default role associated with the trusted-context object.

ENABLE and DISABLE keywords

The ENABLE keyword specifies that the trusted-context object is created in an enabled state.

The DISABLE keyword specifies that the new trusted-context object is created in a disabled state, and is not enabled for any new trusted connections that are established.

You cannot use the SET Database Object Mode statement of SQL to change the ENABLE or DISABLE attributes of trusted contexts. You must use the ALTER TRUSTED CONTEXT statement if you need to reset the ENABLED or DISABLED mode of a trusted-context.

Examples of trusted-context definitions

Example 1: Create a trusted-context object such that the current user on a trusted connection based on this trusted-context object can be switched to two different user IDs. When the current user of the connection is switched to joe, authentication is not required. However, authentication is required when the current user of the connection is switched to bob. Note that the trusted-context object has a default role called MANAGER. This implies that users working within the confines of this trusted-context object inherit the discretionary access privileges associated with the MANAGER role.

   CREATE TRUSTED CONTEXT appserver
     USER wrjaibi
     DEFAULT ROLE MANAGER
     ENABLE
     ATTRIBUTES (ADDRESS '9.26.113.204')
     WITH USE FOR joe WITHOUT AUTHENTICATION,
       bob WITH AUTHENTICATION;

Example 2: Create a trusted-context object such that the current user of a trusted connection based on this trusted-context object can be switched to any user ID without authentication.

   CREATE TRUSTED CONTEXT securerole
     USER pbird
     ENABLE
     ATTRIBUTES (ADDRESS 'example.ibm.com')
     WITH USE FOR PUBLIC WITHOUT AUTHENTICATION;