4 Authentication Methods

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.

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

• Authentication Using Third-Party Services

  • Kerberos Authentication

  • PKI-Based Authentication

  • Authentication with RADIUS

  • Directory-Based Services

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.

Note:

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

See Also:

• Oracle Database Administrator's Guide for more information about network authentication.

• Oracle Database Advanced Security Administrator's Guide for information about Oracle Enterprise Edition with the Oracle Advanced Security option

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 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.

  See Also:

  • Oracle Internet Directory Administrator's Guide

  • Oracle Database 2 Day DBA

  • Oracle Enterprise Manager Concepts

  • Oracle Enterprise Manager Advanced Configuration

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. This protection is always in force, by default.

• Account Locking

• Password Lifetime and Expiration

• Password History

• 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

• Security Issues for Middle-Tier Applications

• Identity Issues in a Multitier Environment

• Restricted Privileges in a Multitier Environment

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.

Note:

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 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 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:

• SYSOPER lets database administrators perform STARTUP, SHUTDOWN, ALTER DATABASE OPEN/MOUNT, ALTER DATABASE BACKUP, ARCHIVE LOG, and RECOVER. SYSOPER also includes the RESTRICTED SESSION privilege.

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

  Note:

  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:

  • Administrator Security in Chapter 7, "Security Policies"

  • Your Oracle operating system-specific documentation for information about configuring operating system authentication of database administrators

  • Oracle Database Administrator's Guide for information on creation and maintenance of password files

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.

  Note:

  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.