Skip Headers

Oracle® Database Security Guide
10g Release 1 (10.1)

Part Number B10773-01
Go to Documentation Home
Go to Book List
Book List
Go to Table of Contents
Go to Index
Go to Master Index
Master Index
Go to Feedback page

Go to previous page
Go to next page
View PDF

Administering Authentication

Authentication is the process of verifying the identity of a user, device, or other entity in a computer system, often as a prerequisite to granting access to resources in a system.

User Authentication Methods

Oracle provides several means for users to be authenticated before they are allowed to create a database session, as discussed in the following sections:

Topics: You can define users who are ... Links to Topics

identified and authenticated by the database, which is called database authentication.

Database Authentication

authenticated by the operating system or network service, which is called external authentication.

External Authentication

authenticated globally by SSL (Secure Sockets Layer), called global users, whose database access is through global roles, authorized by an enterprise directory.

Global Authentication and Authorization

allowed to connect through a middle-tier server that authenticates the user, assumes that identity, and can enable specific roles for the user. This combination of actions and abilities is called proxy authentication and authorization.

Proxy Authentication and Authorization

Database Authentication

If you choose database authentication for a user, administration of the user account including authentication of that user is performed entirely by Oracle. To have Oracle authenticate a user, specify a password for the user when you create or alter the user. Users can change their password at any time. Passwords are stored in an encrypted format. While usernames can be multibyte, each password must be made up of single-byte characters, even if your database uses a multibyte character set.


Oracle Corporation recommends that you encode user names and passwords in ASCII or EBCDIC characters only, depending on your platform. Doing so will maintain compatibility for supporting future changes to your database character set.

Basing user names or passwords on characters that expand in size when migrated to a new target character set can cause login difficulties. Authentication can fail after such a migration because the encrypted user names and passwords in the data dictionary are not updated during a migration to a new database character set.

For example, assuming the current database character set is WE8MSWIN1252 and the target database character set is UTF8, the user name scött (o with an umlaut) will change from 5 bytes to 6 bytes in UTF8. the user scött will no longer be able to log in.

If user names and passwords are not based on ASCII or EBCDIC characters, then if a migration to a new character set occurs, the affected user names and passwords will need to be reset.

To enhance security when using database authentication, Oracle recommends the use of password management, including account locking, password aging and expiration, password history, and password complexity verification.

See Also:

"Password Management Policy"

Creating a User Who is Authenticated by the Database

The following statement creates a user who is identified and authenticated by Oracle. User scott must specify the password tiger whenever connecting to Oracle.

See Also:

Oracle Database SQL Reference for more information about valid passwords, and how to specify the IDENTIFIED BY clause in the CREATE USER and ALTER USER statements

Advantages of Database Authentication

Following are advantages of database authentication:

External Authentication

When you choose external authentication for a user, the user account is maintained by Oracle, but password administration and user authentication is performed by an external service. This external service can be the operating system or a network service, such as Oracle Net.

With external authentication, your database relies on the underlying operating system or network authentication service to restrict access to database accounts. A database password is not used for this type of login. If your operating system or network service permits, you can have it authenticate users. If you do so, set the initialization parameter OS_AUTHENT_PREFIX, and use this prefix in Oracle user names. The OS_AUTHENT_PREFIX parameter defines a prefix that Oracle adds to the beginning of every user's operating system account name. Oracle compares the prefixed user name with the Oracle user names in the database when a user attempts to connect.

For example, assume that OS_AUTHENT_PREFIX is set as follows:



The text of the OS_AUTHENT_PREFIX initialization parameter is case sensitive on some operating systems. See your operating system specific Oracle documentation for more information about this initialization parameter.

If a user with an operating system account named tsmith is to connect to an Oracle database and be authenticated by the operating system, Oracle checks that there is a corresponding database user OPS$tsmith and, if so, allows the user to connect. All references to a user authenticated by the operating system must include the prefix, as seen in OPS$tsmith.

The default value of this parameter is OPS$ for backward compatibility with previous versions of Oracle. However, you might prefer to set the prefix value to some other string or a null string (an empty set of double quotes: ""). Using a null string eliminates the addition of any prefix to operating system account names, so that Oracle user names exactly match operating system user names.

After you set OS_AUTHENT_PREFIX, it should remain the same for the life of a database. If you change the prefix, any database user name that includes the old prefix cannot be used to establish a connection, unless you alter the user name to have it use password authentication.

Creating a User Who is Authenticated Externally

The following statement creates a user who is identified by Oracle and authenticated by the operating system or a network service. This example assumes that OS_AUTHENT_PREFIX = "".


Using CREATE USER ... IDENTIFIED EXTERNALLY, you create database accounts that must be authenticated by the operating system or network service. Oracle will then rely on this external login authentication when it provides that specific operating system user with access to a specific database user's resources.

See Also:

Oracle Advanced Security Administrator's Guide for more information about external authentication

Operating System Authentication

By default, Oracle allows operating-system-authenticated logins only over secure connections, which precludes using Oracle Net and a shared server configuration. This default restriction prevents a remote user from impersonating another operating system user over a network connection.

Setting REMOTE_OS_AUTHENT to TRUE in the database's initialization parameter file forces the RDBMS to accept the client operating system user name received over a nonsecure connection and use it for account access. Since clients, in general, such as PCs, are not trusted to perform operating system authentication properly, it is very poor security practice to turn on this feature.

The default setting, REMOTE_OS_AUTHENT = FALSE, creates a more secure configuration that enforces proper, server-based authentication of clients connecting to an Oracle database.

Any change to this parameter takes effect the next time you start the instance and mount the database. Generally, user authentication through the host operating system offers faster and more convenient connection to Oracle without specifying a separate database user name or password. Also, user entries correspond in the database and operating system audit trails.

Network Authentication

Network authentication is performed using Oracle Advanced Security, which can be configured to use a third party service such as Kerberos. If you are using Oracle Advanced Security as your only external authentication service, the setting of the parameter REMOTE_OS_AUTHENT is irrelevant, since Oracle Advanced Security only allows secure connections.

Advantages of External Authentication

Following are advantages of external authentication:

Global Authentication and Authorization

Oracle Advanced Security enables you to centralize management of user-related information, including authorizations, in an LDAP-based directory service. Users can be identified in the database as global users, meaning that they are authenticated by SSL and that the management of these users is done outside of the database by the centralized directory service. Global roles are defined in a database and are known only to that database, but authorizations for such roles is done by the directory service.


You can also have users authenticated by SSL, whose authorizations are not managed in a directory; that is, they have local database roles only. See the Oracle Advanced Security Administrator's Guide for details.

This centralized management enables the creation of enterprise users and enterprise roles. Enterprise users are defined and managed in the directory. They have unique identities across the enterprise, and can be assigned enterprise roles that determine their access privileges across multiple databases. An enterprise role consists of one or more global roles, and might be thought of as a container for global roles.

Creating a User Who is Authorized by a Directory Service

You have a couple of options as to how you specify users who are authorized by a directory service.

Creating a Global User

The following statement illustrates the creation of a global user, who is authenticated by SSL and authorized by the enterprise directory service:

    IDENTIFIED GLOBALLY AS 'CN=scott,OU=division1,O=oracle,C=US';

The string provided in the AS clause provides an identifier (distinguished name, or DN) meaningful to the enterprise directory.

In this case, scott is truly a global user. But, the disadvantage here is that user scott must then be created in every database that he must access, plus the directory.

Creating a Schema-Independent User

Creating schema-independent users allows multiple enterprise users to access a shared schema in the database. A schema-independent user is:

The process of creating a schema-independent user is as follows:

  1. Create a shared schema in the database as follows.
  2. In the directory, you now create multiple enterprise users, and a mapping object.

    The mapping object tells the database how you want to map users' DNs to the shared schema. You can either do a full DN mapping (one directory entry for each unique DN), or you can map, for example, every user containing the following DN components to the appschema:


    See the Oracle Internet Directory Administrator's Guide for an explanation of these mappings.

Most users do not need their own schemas, and implementing schema-independent users divorces users from databases. You create multiple users who share the same schema in a database, and as enterprise users, they can access shared schemas in other databases as well.

Advantages of Global Authentication and Global Authorization

Some of the advantages of global user authentication and authorization are the following:

Proxy Authentication and Authorization

It is possible to design a middle-tier server to proxy clients in a secure fashion.

Oracle provides three forms of proxy authentication:

In all cases, the middle-tier server must be authorized to act on behalf of the client by the administrator.

To authorize a middle-tier server to proxy a client use the GRANT CONNECT THROUGH clause of the ALTER USER statement. You can also specify roles that the middle tier is permitted to activate when connecting as the client.

Operations done on behalf of a client by a middle-tier server can be audited.

The PROXY_USERS data dictionary view can be queried to see which users are currently authorized to connect through a middle tier.

Use the REVOKE CONNECT THROUGH clause of ALTER USER to disallow a proxy connection.

See Also:

Authorizing a Middle Tier to Proxy and Authenticate a User

The following statement authorizes the middle-tier server appserve to connect as user bill. It uses the WITH ROLE clause to specify that appserve activate all roles associated with bill, except payroll.


To revoke the middle-tier server's (appserve) authorization to connect as user bill, the following statement is used:


Authorizing a Middle Tier to Proxy a User Authenticated by Other Means

Use the AUTHENTICATED USING clause of the ALTER USER ... GRANT CONNECT THROUGH statement to authorize a user to be proxied, but not authenticated, by a middle tier. Currently, PASSWORD is the only means supported.

The following statement illustrates this form of authentication:


In the preceding statement, middle-tier server midtier is authorized to connect as mary, and midtier must also pass mary's password to the database server for authorization.