Key Terminology

Familiarize yourself with the key terminology used within the Oracle Deep Data Security (Deep Sec) environment.

Identities and users

These terms describe the users and identities that Deep Sec recognizes for authentication and authorization.

• IAM

  An identity and access management (IAM) system, such as Microsoft Entra ID, Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), or Keycloak, that manages user identities and role assignments outside the database.

• End user

  A user of an application who does not own database schemas or database objects. An end user can be:

  • A user whose identity is managed in IAM. Typically, they connect to the database through the application. They can also log in directly using token-based authentication.

  • A user created and managed in the database using the CREATE END USER statement. End users managed in the database can log in directly using password authentication (or using password authentication with a configured second factor). Additionally, they can be mapped by user name to users managed in the application’s own user store, so that those users can connect through the application’s trust, without requiring direct password authentication on the database server.

• Application identity

  A database-resident identity for a specific application or AI agent. The database enables the data roles granted to an application identity for all end users who connect through that application, giving them common privileges. In addition, an application identity can serve as a logon principal: an application or AI agent can log on as its application identity to establish the database connection on which it attaches end-user security context payloads, or to access data directly under its own authorization.

Roles and authorizations

These terms distinguish between roles defined in IAM and their corresponding representations within the database.

• Application role

  A role your application defines to control access to protected resources. You usually create and assign these roles to users in IAM, and then create a corresponding data role in the database that maps to each application role.

• Data role

  A role in the database used for fine-grained access to data. You can grant data privileges (through data grants) and standard database roles to a data role. A data role can be:

  • Mapped to an application role in IAM using the MAPPED TO clause. The database automatically enables it when the end user’s token includes the corresponding role claim.

  • Managed locally in the database. A data role managed locally in the database can be granted to end users, application identities, or other data roles (that are managed locally).

• Database role

  A standard role that exists within the Oracle AI Database environment, separate from the application-specific roles defined above.

Application and contexts

These terms describe the application that accesses the database and the two context objects involved in a Deep Sec session.

• Application

  A client application in a two-tier architecture, or a mid-tier application in a three-tier architecture, that accesses the database using language-specific client drivers such as JDBC, Python, or ODP.NET.

• End-user security context (runtime values within a database session)

  The session-level object that holds the active identity, enabled data roles, and live attribute values. The identity can represent an end user or an application. The database establishes an end-user security context when an application sends an end-user security context payload with the following components:

  • Identity information: For IAM-managed identities, the database derives the identity from the end-user token when it is supplied, or from the database-access token when the separate end-user token is omitted. See About the End-User Security Context for the Microsoft Entra ID and OCI IAM token types that allow this omission. For end users managed locally, supply the name of the end user created in the database.

  • Data roles (optional): Additional data roles that the application can enable for the end-user security context, beyond those mapped to application roles in IAM and those enabled by default for the application identity.

  • End-user context attributes (optional): A dictionary of application-defined key-value pairs to include in the security context. Used when data grants or application logic rely on custom end-user context attributes.

  • Database-access token: An OAuth 2.0 access token that the application obtains from IAM through an on-behalf-of (OBO) flow or a client credentials flow to authorize its access to the database. This token ensures the database accepts requests only from trusted applications. Only an authorized application (with its application secret) can obtain this token from IAM. When the separate end-user token is omitted, the database also uses the database-access token for authentication and authorization.

• End-user context (database-side definition)

  A database schema object you create with the CREATE END USER CONTEXT command that defines a set of attributes, their data types, default values, and optional PL/SQL routines to populate them. At runtime, the database uses this object as a template for JSON-style name-value pairs and instantiates it on first use in the current end-user security context — either when the application payload is attached or when an attribute is required for authorization checks.

Access control mechanisms

These terms define how Deep Sec protects specific data elements.

• Data grant

  A fine-grained access control policy that allows access to database records at row, column, and cell levels.

• Predicate

  A logical condition expressed as a SQL predicate that identifies a specific set of rows for access control purposes.

• Data privilege

  A specific right or permission that you grant through data grants to an end user or a data role.

Authentication terms

These terms describe multifactor authentication for end users managed in the database who connect directly.

• Multifactor authentication (MFA)

  A security method that requires a user to verify their identity using two or more independent factors before a database session is established. For local end users, MFA combines password authentication (the primary factor) with a second factor delivered through an external authenticator.

• Authentication factor

  A category of credential used to prove identity. Deep Sec supports a password as a knowledge factor and a registered mobile authenticator as a possession factor.

• Authenticator

  An application, device, or service that generates or delivers the verification evidence as a second factor (such as a one-time passcode or a push notification) for user sign-in. Deep Sec supports the following push-based authenticators: Cisco Duo and Oracle Mobile Authenticator (OMA).

• Push notification

  A second-factor verification method in which a prompt is sent to a registered mobile device. The user approves or denies the sign-in request in an authenticator.

Token technologies

These terms distinguish the token technologies that Deep Sec supports for IAM-managed identities.

• OAuth 2.0 access token

  A bearer access token issued by IAM to authorize access to a specific protected resource. In Deep Sec, you can use OAuth 2.0 access tokens as end-user tokens and database-access tokens.

• OCI IAM auth token

  A scoped proof-of-possession token issued by OCI IAM for database authentication and bound to a public key. To use the token, the client must provide cryptographic proof generated with the corresponding private key. Unlike a bearer token, possession of the token alone is insufficient. This token is specific to OCI IAM.