Role membership inheritance through a trusted context

The current user of a trusted connection can acquire additional privileges through the automatic inheritance of a role through the trusted context, if this was specified by the security administrator as part of the relevant trusted context definition.

A role can be inherited by all users of the trusted connection by default. The security administrator can also use the trusted context definition to specify a role for specific users to inherit.

The active roles that a session authorization ID can hold while on a trusted connection are:
  • The roles of which the session authorization ID is normally considered a member, plus
  • Either the trusted context default role or the trusted context user-specific role, if they are defined
Note:
  • A trusted context role can be inherited only through connections where the system authorization ID and session authorization ID values are the same. You can configure user authentication by using a custom security plugin that produces separate system authorization ID and session authorization ID values upon a successful connection. When these values are different, a trusted contexts role cannot be inherited through that connection, even if it is a trusted connection.
  • Trusted context privileges that are acquired through a role are effective only for the following authorization checks within the session:
    • CONNECT privilege on the database
    • USAGE privilege on a workload
    • EXECUTE privilege on a package
    • dynamic DML operations.

Acquiring trusted context user-specific privileges

The security administrator can use the trusted context definition to associate roles with a trusted context so that:
  • All users of the trusted connection can inherit a specified role by default
  • Specific users of the trusted connection can inherit a specified role

When the user on a trusted connection is switched to a new authorization ID and a trusted context user-specific role exists for this new authorization ID, the user-specific role overrides the trusted context default role, if one exists, as demonstrated in the example.

Example of creating a trusted context that assigns a default role and a user-specific role

Suppose that the security administrator creates the following trusted context object:
CREATE TRUSTED CONTEXT CTX1
 	BASED UPON CONNECTION USING SYSTEM AUTHID USER1 
	ATTRIBUTES (ADDRESS   '192.0.2.1') 
  WITH USE FOR USER2 WITH AUTHENTICATION,  
               USER3 WITHOUT AUTHENTICATION  
  DEFAULT ROLE AUDITOR
  ENABLE
When USER1 establishes a trusted connection, the privileges granted to the role AUDITOR are inherited by this authorization ID. Similarly, these same privileges are also inherited by USER3 when the current authorization ID on the trusted connection is switched to his or her user ID. (If the user ID of the connection is switched to USER2 at some point, then USER2 would also inherit the trusted context default role, AUDITOR.) The security administrator may choose to have USER3 inherit a different role than the trusted context default role. They can do so by assigning a specific role to this user as follows:
CREATE TRUSTED CONTEXT CTX1
	BASED UPON CONNECTION USING SYSTEM AUTHID USER1
	ATTRIBUTES (ADDRESS   '192.0.2.1')
  WITH USE FOR USER2 WITH AUTHENTICATION, 
               USER3 WITHOUT AUTHENTICATION ROLE OTHER_ROLE
  DEFAULT ROLE AUDITOR
  ENABLE
When the current user ID on the trusted connection is switched to USER3, this user no longer inherits the trusted context default role. Rather, they inherit the specific role, OTHER_ROLE, assigned to him or her by the security administrator.