|Oracle® Database Security Guide
10g Release 1 (10.1)
Part Number B10773-01
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.
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|
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
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.
The following statement creates a user who is identified and authenticated by Oracle. User
scott must specify the password
tiger whenever connecting to Oracle.
Oracle Database SQL Reference for more information about valid passwords, and how to specify the
Following are advantages of database 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
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
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.
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 = "".
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.
Oracle Advanced Security Administrator's Guide for more information about external 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.
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 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.
Following are advantages of external authentication:
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.
You have a couple of options as to how you specify users who are authorized by a directory service.
The following statement illustrates the creation of a global user, who is authenticated by SSL and authorized by the enterprise directory service:
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 schema-independent users allows multiple enterprise users to access a shared schema in the database. A schema-independent user is:
CREATE USERstatement of any type
The process of creating a schema-independent user is as follows:
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
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.
Some of the advantages of global user authentication and authorization are the following:
CURRENT_USERdatabase links connect as a global user. A local user can connect as a global user in the context of a stored procedure--without storing the global user's password in a link definition.
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.
PROXY_USERS data dictionary view can be queried to see which users are currently authorized to connect through a middle tier.
REVOKE CONNECT THROUGH clause of
ALTER USER to disallow a proxy connection.
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
To revoke the middle-tier server's (
appserve) authorization to connect as user
bill, the following statement is used:
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
midtier must also pass
mary's password to the database server for authorization.