4 Authentication Methods

Authentication means verifying the identity of someone (a user, device, or an entity) who wants to access data, resources, or applications. Validating that identity establishes a trust relationship for further interactions. Authentication also enables accountability by making it possible to link access and actions to specific identities. After authentication, authorization processes can allow or limit the levels of access and action permitted to that entity as described in Chapter 5, "Authorization: Privileges, Roles, Profiles, and Resource Limitations".

Oracle allows a single database instance to use any or all methods. Oracle requires special authentication procedures for database administrators, because they perform special database operations. Oracle also encrypts passwords during transmission to ensure the security of network authentication.

To validate the identity of database users and prevent unauthorized use of a database user name, you can authenticate users by using any combination of the methods described in the following sections:

Authentication Considerations About ... Links to Topics
Operating Systems Authentication by the Operating System
Networks and LDAP Directories Authentication by the Network
Databases Authentication by Oracle Database
Multitier Systems Multitier Authentication and Authorization
Secure Socket Layer Usage Authentication of Database Administrators
Database Administrators Authentication of Database Administrators

See Also:

Authentication by the Operating System

Some operating systems permit Oracle to use information they maintain to authenticate users. This has the following benefits:

  • Once authenticated by the operating system, users can connect to Oracle more conveniently, without specifying a user name or password. For example, an operating-system-authenticated user can invoke SQL*Plus and skip the user name and password prompts by entering the following:

    SQLPLUS / 
  • With control over user authentication centralized in the operating system, Oracle need not store or manage user passwords, though it still maintains user names in the database.

  • Audit trails in the database and operating system can use the same user names.

When an operating system is used to authenticate database users, managing distributed database environments and database links requires special care.

See Also:

  • Oracle Database Administrator's Guide sections on (and index entries for) authentication, operating systems, distributed database concepts, and distributed data management

  • Operating system-specific documentation by Oracle for more information about authenticating by using your operating system

Authentication by the Network

Authentication over a network is handled by the SSL protocol or by third-party services as described in the following subsections:

Authentication Using SSL

The Secure Socket Layer (SSL) protocol is an application layer protocol. It can be used for user authentication to a database, and it is independent of global user management in Oracle Internet Directory. That is, users can use SSL to authenticate to the database even without a directory server in place.

Authentication Using Third-Party Services

Authentication over a network makes use of third-party network authentication services. Prominent examples include Kerberos, Public Key Infrastructure (PKI), the Remote Authentication Dial-In User Service (RADIUS), and directory-based services, as described in the following subsections.

If network authentication services are available to you, then Oracle can accept authentication from the network service. If you use a network authentication service, then some special considerations arise for network roles and database links.


To use a network authentication service with Oracle, you need Oracle Enterprise Edition with the Oracle Advanced Security option.

See Also:

Kerberos Authentication

Kerberos is a trusted third-party authentication system that relies on shared secrets. It presumes that the third party is secure, and provides single sign-on capabilities, centralized password storage, database link authentication, and enhanced PC security. It does this through a Kerberos authentication server, or through Cybersafe Active Trust, a commercial Kerberos-based authentication server.

See Also:

Oracle Database Advanced Security Administrator's Guide for more information about Kerberos.

PKI-Based Authentication

Authentication systems based on PKI issue digital certificates to user clients, which use them to authenticate directly to servers in the enterprise without directly involving an authentication server. Oracle provides a PKI for using public keys and certificates, consisting of the following components:

  • Authentication and secure session key management using SSL.

  • Oracle Call Interface (OCI) and PL/SQL functions

    These are used to sign user-specified data using a private key and certificate. The verification of the signature on data is done by using a trusted certificate.

  • Trusted certificates

    These are used to identify third-party entities that are trusted as signers of user certificates when an identity is being validated. When the user certificate is being validated, the signer is checked by using trust points or a trusted certificate chain of certificate authorities stored in the validating system. If there are several levels of trusted certificates in this chain, then a trusted certificate at a lower level is simply trusted without needing to have all its higher-level certificates reverified.

  • Oracle wallets

    These are data structures that contain the private key of a user, a user certificate, and the set of trust points of a user (trusted certificate authorities).

  • OracleAS Certificate Authority

    This is a component of the Oracle Identity Management infrastructure, which provides an integrated solution for provisioning X.509 version 3 certificates for individuals, applications, and servers that require certificates for PKI-based operations such as authentication, SSL, S/MIME, and so on.

  • Oracle Wallet Manager

    This is a standalone Java application used to manage and edit the security credentials in Oracle wallets. It performs the following operations:

    • Protects user keys

    • Manages X.509 version 3 certificates on Oracle clients and servers

    • Generates a public-private key pair and creates a certificate request for submission to a certificate authority

    • Installs a certificate for the entity

    • Configures trusted certificates for the entity

    • Creates wallets

    • Opens a wallet to enable access to PKI-based services

  • X.509 version 3 certificates obtained from (and signed by) a trusted entity, a certificate authority. Because the certificate authority is trusted, these certificates certify that the requesting entity's information is correct and that the public key on the certificate belongs to the identified entity. The certificate is loaded into an Oracle wallet to enable future authentication.

Oracle public key infrastructure is illustrated in Figure 4-1.

Figure 4-1 Oracle Public Key Infrastructure

Description of Figure 4-1 follows
Description of "Figure 4-1 Oracle Public Key Infrastructure"

Authentication with RADIUS

Oracle supports remote authentication of users through the Remote Authentication Dial-In User Service (RADIUS), a standard lightweight protocol used for user authentication, authorization, and accounting.

See Also:

Oracle Database Advanced Security Administrator's Guide for information about Oracle Advanced Security

Directory-Based Services

Using a central directory can make authentication and its administration extremely efficient. Directory-based sevices include the following:

  • Oracle Internet Directory, which uses the Lightweight Directory Access Protocol (LDAP), enables information about users (called enterprise users) to be stored and managed centrally. Although database users must be created (with passwords) in each database that they need to access, enterprise user information is accessible centrally in the Oracle Internet Directory. You can also integrate this directory with Active Directory and iPlanet.

    Oracle Internet Directory lets you manage the security attributes and privileges for users, including users authenticated by X.509 certificates. Oracle Internet Directory also enforces attribute-level access control. This feature enables read, write, or update privileges on specific attributes to be restricted to specific users, such as an enterprise security administrator. Directory queries and responses can use SSL encryption for enhanced protection during authentication and other interactions.

  • Oracle Enterprise Security Manager, which provides centralized privilege management to make administration easier and increase security levels. Oracle Enterprise Security Manager lets you store and retrieve roles from Oracle Internet Directory.

Authentication by Oracle Database

Oracle Database can authenticate users attempting to connect to a database, by using information stored in that database itself. To set up Oracle Database to use database authentication, you must create each user with an associated password. The user must provide this user name and password when attempting to establish a connection. This process prevents unauthorized use of the database, because the connection will be denied if the user provides an incorrect password. Oracle Database stores user passwords in the data dictionary in an encrypted format to prevent unauthorized alteration. Users can change their passwords at any time.

To identify the authentication protocols that are allowed by a client or a database, a DBA can explicitly set the SQLNET.ALLOWED_LOGON_VERSION parameter in the server sqlnet.ora file. Then each connection attempt is tested, and if the client or server does not meet the minimum version specified by its partner, authentication fails with an ORA-28040 error. The parameter can take the values 10, 9, or 8, which is the default. These values represent database server versions. Oracle recommends the value 10.

Database authentication includes the following features:

Password Encryption While Connecting

Passwords are always automatically and transparently encrypted during network (client/server and server/server) connections, using AES (Advanced Encryption Standard) before sending them across the network.

See Also:

For more information about encrypting passwords in network systems, refer to:

Account Locking

Oracle can lock a user's account after a specified number of consecutive failed login attempts. You can configure the account to unlock automatically after a specified time interval or to require database administrator intervention to be unlocked.

Use the CREATE PROFILE statement to establish how many failed login attempts a user can attempt before the account locks, and how long it remains locked before it unlocks automatically.

The database administrator can also lock accounts manually, so that they cannot unlock automatically but must be unlocked explicitly by the database administrator.

See Also:



Failed login attempts will be limited by default in future Oracle Database releases.

Password Lifetime and Expiration

The database administrator can specify a lifetime for passwords, after which they expire and must be changed before account login is again permitted. A grace period can be established, during which each attempt to login to the database account receives a warning message to change the password. If it is not changed by the end of that period, then the account is locked. No further logins to that account are allowed without assistance by the database administrator.

The database administrator can also set the password state to expired, causing the user account status to change to expired. The user or the database administrator must then change the password before the user can log in to the database.

Password History

The password history option checks each newly specified password to ensure that a password is not reused for a specified amount of time or for a specified number of password changes. The database administrator can configure the rules for password reuse with CREATE PROFILE statements.

See Also:

Password Complexity Verification

Complexity verification checks that each password is complex enough to provide reasonable protection against intruders who try to break into the system by guessing passwords.

The sample Oracle password complexity verification routine (the PL/SQL script UTLPWDMG.SQL, which sets the default profile parameters) checks that each password meet the following requirements:

  • Be a minimum of four characters in length

  • Not equal the userid

  • Include at least one alphabet character, one numeric character, and one punctuation mark

  • Not match any word on an internal list of simple words like welcome, account, database, user, and so on

  • Differ from the previous password by at least three characters

    See Also:

    Discussion about Password Complexity Verification.

Multitier Authentication and Authorization

In a multitier environment, Oracle controls the security of middle-tier applications by limiting their privileges, preserving client identities through all tiers, and auditing actions taken on behalf of clients. In applications that use a heavy middle tier, such as a transaction processing monitor, the identity of the clients connecting to the middle tier must be preserved. One advantage of using a middle tier is connection pooling, which allows multiple users to access a data server without each of them needing a separate connection. In such environments, you need to be able to set up and break down connections very quickly.

For these environments, Oracle database administrators can use the Oracle Call Interface to create lightweight sessions, which allow database password authentication for each user. This method preserves the identity of the real user through the middle tier without the overhead of a separate database connection for each user.

You can create lightweight sessions with or without passwords. However, if a middle tier is outside or on a firewall, then security is better when each lightweight session has its own password. For an internal application server, lightweight sessions without passwords might be appropriate.

Issues of administration and security in multitier environments are discussed in the following sections:

Clients, Application Servers, and Database Servers

In a multitier environment, an application server provides data for clients and serves as an interface from them to one or more database servers. The application server can validate the credentials of a client, such as a web browser, and the database server can audit operations performed by the application server. These auditable operations include actions performed by the application server on behalf of clients, such as requests that information be displayed on the client. A request to connect to the database server is an example of an application server operation not related to a specific client.


While client-side authentication is possible, Oracle strongly recommends disabling it by setting the remote_os_authentication parameter to FALSE.

Authentication in a multitier environment is based on trust regions. Client authentication is the domain of the application server. The application server itself is authenticated by the database server. The following operations are performed:

  • The client provides proof of authenticity to the application server, typically, by using a password or an X.509 certificate.

  • The application server authenticates the client and then authenticates itself to the database server.

  • The database server authenticates the application server, verifies that the client exists, and verifies that the application server has the privilege to connect for this client.

Application servers can also enable roles for a client on whose behalf they connect. The application server can obtain these roles from a directory, which thus serves as an authorization repository. The application server can only request that these roles be enabled. The database verifies the following requirements:

  • That the client has these roles by checking its internal role repository

  • That the application server has the privilege to connect on behalf of the user, and thus to use these roles as the user could

Figure 4-2 shows an example of multitier authentication.

Figure 4-2 Multitier Authentication

Description of Figure 4-2 follows
Description of "Figure 4-2 Multitier Authentication"

Security Issues for Middle-Tier Applications

Security for middle-tier applications must address the following key issues:

  • Accountability: The database server must be able to distinguish between the actions of a client and the actions an application takes on behalf of a client. It must be possible to audit both kinds of actions.

  • Differentiation: The database server must be able to distinguish between a client accessing the database directly and an application server acting either for itself or on behalf of a browser client.

  • Least privilege: Users and middle tiers should be given the fewest privileges necessary to perform their actions, to minimize the danger of inadvertent or malicious unauthorized activities.

Identity Issues in a Multitier Environment

Multitier authentication maintains the identity of the client through all tiers of the connection in order to maintain useful audit records. If the identity of the originating client is lost, then specific accountability of that client is lost. It becomes impossible to distinguish operations performed by the application server on behalf of the client from those done by the application server by itself.

Restricted Privileges in a Multitier Environment

Privileges in a multitier environment must be limited to those necessary to perform the requested operation.

Client Privileges

Client privileges must be as limited as possible in a multitier environment. Operations are performed on behalf of the client by the application server.

Application Server Privileges

Application server privileges in a multitier environment must also be limited, so that the application server cannot perform unwanted or unneeded operations while performing a client operation.

See Also:

Chapter 10, "Administering Authentication", and the Oracle Database Administrator's Guide, for more information about multitier authentication

Authentication of Database Administrators

Database administrators perform special operations (such as shutting down or starting up a database) that should not be performed by normal database users. Oracle provides for secure authentication of database administrator user names, for which you can choose either operating system authentication or password files.

Figure 4-3 illustrates the choices you have for database administrator authentication schemes. Different choices apply to administering your database locally (on the machine where the database resides) and to administering many different database machines from a single remote client.

Figure 4-3 Database Administrator Authentication Methods

Description of Figure 4-3 follows
Description of "Figure 4-3 Database Administrator Authentication Methods"

Operating system authentication for a database administrator typically involves establishing a group on the operating system, assigning DBA privileges to that group, and then adding the names of persons who should have those privileges to that group. On UNIX systems, the special group is called the dba group.

On Microsoft Windows systems, users who connect with the SYSDBA privilege can take advantage of the Windows native authentication. If these users work with Oracle Database using their domain accounts, then you must explicitly grant them local administrative privileges and ORA_DBA membership.

The database uses password files to keep track of those database user names that have been granted the SYSDBA and SYSOPER privileges. These privileges enable the following operations and capabilities:


  • SYSDBA has all system privileges with ADMIN OPTION, including the SYSOPER system privilege, and permits CREATE DATABASE and time-based recovery.


    Connections requested AS SYSDBA or AS SYSOPER must use these phrases; without them, the connection fails. The Oracle parameter 07_DICTIONARY_ACCESSIBILITY is set to FALSE by default, to limit sensitive data dictionary access only to those authorized. The parameter also enforces the required AS SYSDBA or AS SYSOPER syntax.

    See Also:

Oracle Database 10g Release 2 (10.2) enhances password file based authentication by making it easier to use. The following enhancements have been made:

  • Password file based authentication is enabled by default. This means that the database is ready to use a password file for authenticating users that have SYSDBA or SYSOPER system privileges. Password file based authentication is activated as soon as you create a password file using the ORAPWD utility.

  • A password file containing users with SYSDBA or SYSOPER privileges can be shared between different databases. You can have a shared password file that contains users in addition to the SYS user.


    In order to share a password file between different databases, the REMOTE_LOGIN_PASSWORDFILE parameter needs to be changed to SHARED in the init.ora file. The default value of this parameter is EXCLUSIVE. This is the recommended setting.