Configure Safe User ID in a multi-tenant database

Safe User ID policies

The Safe User ID policies work with the Activate and Deactive event policies in the ABL application. These event procedures are optional, but they provide convienent execution points in a client request for asserting the safe user identity. You cannot bind the execution of the Safe User ID feature with the need to write and configure an Activate or Deactivate procedure.

The Safe User ID policy determines when, during the execution of a client request, the safe user identity is set on the database connection. You can choose from the following policies:

• preact—Sets the Safe User ID on the database connection before an Activate procedure is executed in the ABL application, if one is configured, on behalf of a client request. The ABL application's Activate procedure accesses the database connection using the safe user identity.

  If an Activate procedure is not configured, the client request begins execution as the safe user identity.

• postact—Sets the Safe User ID on the database connection after any Activate procedure would complete execution in the ABL application. The implication of this setting is that the ABL application's Activate procedure code accesses the database connection using the same client identity and tenant used by the last client ABL request. When the client request begins execution, any database access will begin by using the safe user identity.

  If the Activate Procedure fails or returns an error, and the safe user ID policy is postact, the current user (and tenant) of the database connection remains unchanged.

  If the setting of the safe user identity on a database connection fails, the Activate procedure, or client request if no Activate procedure exists, terminates with an internal error and the database connection becomes locked and its user identity (and tenant) remains with its previous identity.

• predeact—Sets the Safe User ID on the database connection before any configured Deactivate procedure is executed. An ABL application;s Deactivate code will access the database connection using the safe user identity. After any Deactivate procedure is executed, the database connection’s current user identity is set to the safe user identity.
• postdeact—Sets the Safe User ID on the database connection after the Deactivate procedure is executed in the ABL application, if one is configured. The implication of this setting is that the ABL application's Deactivate event procedure accesses the database connection using the same client identity and tenant used by the last client ABL request.

  If the Deactivate procedure fails, and the safe user ID policy is postdeact, the database connection's current user identity is changed to the safe user identity. The intention is that the next request begins its execution using the safe user identity.

  If the setting of the safe user identity fails on a database connection, the Deactivate procedure does not terminate and the database connection is locked and its user identity (and tenant) remains with its previous identity. Note that the ABL application is not able to trap, dismiss, for act upon the error because it occurs outside of the AVM run-time.

Configure Safe User ID using OpenEdge Management

To configure Safe User ID using OpenEdge Management:

1. Start OpenEdge Management.
2. In the Manage Database Connection page, click Edit security options.

   The Database Security Options page is displayed.

3. In the Safe User Id dropdown box, select one of the following options:
   • off (Default)
   • preact
   • postact
   • predeact
   • postdeact

Configure Safe User ID using the Database Policy Utility

To configure Safe User ID using the Database Policy Utility, dbpolicyutil:

1. Start the Database Policy Utility:

   proenv>dbpolicyutil

2. Enter the set safeUserIdPolicy command using the following syntax:

   set safeUserIdPolicy=policy-options -db db-name

In the dbpolicyutil command syntax:

• policy-options represents one of the following policy strings:
  • preact
  • postact
  • predeact
  • postdeact
• db-name represents the name of the multi-tenant database.

For complete details about the Database Policy Utility, see Database Security Policy Reference.

Safe User ID configuration best practices

Note the following best practices regarding the configuration of the Safe User ID feature:

• The DBA can change the Safe User ID policy at any time, but should not. The reason for this is that the ABL developers code the Activate and Deactivate event procedures based upon their chosen identity management design. This design is coded to support a certain policy behavior.

  If the DBA makes a change to the configuration of Safe User ID policy to something other than what the ABL developer has specified, unpredictable results may occur.

• Because Safe User ID is a PAS for OpenEdge feature, the ABL session’s database connection’s safe user identity is established at initial database connection time. The safe user identity must not change until the ABL session disconnects the database and executes another connect operation.

  ABL sessions may start and terminate at any time, implicitly connecting and disconnecting databases. Within that time span of a database connection, the Safe User ID policy and safe user identity must remain consistent to produce consistent identity management behavior, and therefore consistent application behavior. The restart of the ABL session and execution of the Activate and Deactivate event procedures must be irrelevant in this regard. Therefore, this database Safe User ID connection behavior would also need to be consistent with that of new ABL database re-connection activity.