| Oracle® Database Security Guide 10g Release 2 (10.2) Part Number B14266-01 |
|
|
View PDF |
| Oracle® Database Security Guide 10g Release 2 (10.2) Part Number B14266-01 |
|
|
View PDF |
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 |
|---|---|
| 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 Secure Sockets Layer (SSL), 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 |
If you choose database authentication for a user, then administration of the user account including authentication of that user is performed entirely by Oracle Database. To have Oracle Database 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 user names can be multibyte, each password must be made up of single-byte characters, even if your database uses a multibyte character set.
|
Note: Oracle 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.By using 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 and a migration to a new character set occurs, then 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 Database. User scott must specify the password tiger whenever connecting to Oracle Database.
CREATE USER scott IDENTIFIED BY tiger;
|
See Also: Oracle Database SQL Reference for more information about valid passwords, and how to specify theIDENTIFIED BY clause in the CREATE USER and ALTER USER statements |
Following are the advantages of database authentication:
User accounts and all authentication are controlled by the database. There is no reliance on anything outside of the database.
Oracle provides strong password management features to enhance security when using database authentication.
It is easier to administer when there are small user communities.
When you choose external authentication for a user, the user account is maintained by Oracle Database, 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, then you can have it authenticate users. Set the initialization parameter OS_AUTHENT_PREFIX, and use this prefix in Oracle Database user names. The OS_AUTHENT_PREFIX parameter defines a prefix that Oracle Database 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:
OS_AUTHENT_PREFIX=OPS$
|
Note: The text of theOS_AUTHENT_PREFIX initialization parameter is case-sensitive on some operating systems. Refer to 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 installation and be authenticated by the operating system, then Oracle Database 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, OPS$, as seen in OPS$tsmith.
The default value of this parameter is OPS$ for backward compatibility with previous versions of Oracle Database. 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, then 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 scott IDENTIFIED EXTERNALLY;
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 the database resources of a specific user.
|
See Also: Oracle Database 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.
Setting REMOTE_OS_AUTHENT to TRUE in the database 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. Because 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, then the REMOTE_OS_AUTHENT parameter setting is irrelevant, because Oracle Advanced Security only allows secure connections.
Following are the advantages of external authentication:
More choices of authentication mechanism are available, such as smart cards, fingerprints, Kerberos, or the operating system.
Many network authentication services, such as Kerberos support single sign-on, enabling users to have fewer passwords to remember.
If you are already using some external mechanism for authentication, such as one of those listed earlier, then there may be less administrative overhead to use that mechanism with the database as well.
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.
|
Note: You can also have users authenticated by SSL, whose authorizations are not managed in a directory, that is, they have local database roles only. Refer to the Oracle Database 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 with a private schema, authenticated by SSL, and authorized by the enterprise directory service:
CREATE USER scott
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.
Multiple enterprise users can share a single schema in the database. These users are authorized by the enterprise directory service but do not own individual private schemas in the database. These users are not individually created in the database. They connect to a shared schema in the database.
The process of creating a schema-independent user is as follows:
Create a shared schema in the database as follows.
CREATE USER appschema INDENTIFIED GLOBALLY AS '';
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:
OU=division,O=Oracle,C=US
|
See Also: Refer to the Oracle Database Enterprise User 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:
Provides strong authentication using SSL, Kerberos, or Windows NT native authentication
Enables centralized management of users and privileges across the enterprise
Is easy to administer: You do not have to create a schema for every user in every database in the enterprise
Facilitates single sign-on: Users only need to sign on once to access multiple databases and services. Further, users using passwords can have a single password to access multiple databases accepting password-authenticated enterprise users.
Because global user authentication and authorization provide password-based access, previously defined password-authenticated database users can be migrated to the directory (using the User Migration Utility) to be centrally administered. This makes global authentication and authorization available for prior Oracle release clients that are still supported.
CURRENT_USER database links connect as a global user. A local user can connect as a global user in the context of a stored procedure, that is, without storing the global user password in a link definition.
|
See Also: The following books contain additional information about global authentication and authorization and enterprise users and roles: |
It is possible to design a middle-tier server to proxy clients in a secure fashion.
Oracle provides three forms of proxy authentication:
The middle-tier server authenticates itself with the database server and a client, in this case an application user or another application, authenticates itself with the middle-tier server. Client identities can be maintained all the way through to the database.
The client, in this case a database user, is not authenticated by the middle-tier server. The clients identity and database password are passed through the middle-tier server to the database server for authentication.
The client, in this case a global user, is authenticated by the middle-tier server, and passes one of the following through the middle tier for retrieving the client's user name.
Distinguished name (DN)
Certificate
|
Note: The use of certificates for proxy authentication may not be supported in future Oracle Database releases. |
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:
|
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.
ALTER USER bill
GRANT CONNECT THROUGH appserve
WITH ROLE ALL EXCEPT payroll;
To revoke the middle-tier server (appserve) authorization to connect as user bill, the following statement is used:
ALTER USER bill REVOKE CONNECT THROUGH appserve;
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:
ALTER USER mary
GRANT CONNECT THROUGH midtier
AUTHENTICATED USING PASSWORD;
In the preceding statement, middle-tier server midtier is authorized to connect as user mary, and midtier must also pass the user password to the database server for authorization.
