Skip Headers

Oracle9i Security Overview
Release 2 (9.2)

Part Number A96582-01
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

4
Authenticating Users to the Database

Authentication of user identity is imperative in distributed environments. Without it, there can be little confidence in network or database security. This chapter contains these sections:

Introduction to User Authentication

A basic security requirement is that you know your users: you must first identify users before you can determine their privileges and access rights. You must know who a user is so that you can audit his or her actions upon the data.

Users can be authenticated in a number of different ways before they are allowed to create a database session. In database authentication, you can define users such that the database performs both identification and authentication of users. In external authentication, you can define users such that authentication is performed by the operating system or network service. Alternatively, you can define users such that they are authenticated by the Secure Sockets Layer (SSL). For enterprise users, an enterprise directory can be used to authorize their access to the database through enterprise roles. Finally, you can specify users who are allowed to connect through a middle-tier server. The middle-tier server authenticates and assumes the identity of the user and is allowed to enable specific roles for the user. This is called proxy authentication.

Passwords for Authentication

Passwords are one of the basic forms of authentication. A user must provide the correct password when establishing a connection to prevent unauthorized use of the database. In this way, users attempting to connect to a database can be authenticated by using information stored in that database. Passwords are assigned when users are created. A database can store a user's password in the data dictionary in an encrypted format. Users can change their passwords at any time.

Database security systems that are dependent on passwords require that passwords be kept secret at all times. But, passwords are vulnerable to theft, forgery, and misuse. A number of steps can strengthen the basic password feature and provide greater control over database security:

Strong Authentication

Having a central facility authenticate all members of the network (clients to servers, servers to servers, users to both clients and servers) is one effective way to address the threat of nodes on a network falsifying their identities. Strong authentication can also be established by using two-factor authentication: the combination of something a user knows (such as a PIN), and something the user has (such as a token card).

Strong authentication has important advantages:

This section describes the following strong authentication methods that can be used in a distributed environment:

See Also:

"Authentication and Access Controls in Oracle9i"



Kerberos and CyberSafe

Kerberos is a trusted third-party authentication system that was created by the Massachusetts Institute of Technology. It is provided free of charge on the Internet.

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

Kerberos single signon provides a number of benefits. With only one centralized password store, it reduces the administrative overhead and requires users to remember only one password. It enables network access time to be controlled, and by means of DES encryption and CRC-32 integrity, it secures against unauthorized access and packet replay. Further, it enables current user database links. Kerberos-enabled databases can propagate a client's identity to the next database for Kerberos users connecting with single signon through Kerberos.

CyberSafe is a commercial version of Kerberos, which adds certain extra features and support, including support for the CyberSafe ActiveTrust server. CyberSafe centralizes security and provides single signon. Like Kerberos, it is based on passwords, but provides a much stronger authentication mechanism.

See Also:

"Kerberos and CyberSafe with Oracle Advanced Security"



RADIUS

The RADIUS protocol (Remote Authentication Dial-In User Service) is an industry standard protocol adopted by authentication vendors as a common communication method. RADIUS provides user authentication, authorization and accounting between a client and an authentication server. It has been implemented by almost all organizations enabling users to access the network remotely. Enterprises have standardized on RADIUS because of its widespread acceptance in the industry, its flexibility, and its ability to centralize all user information in order to ease and reduce the cost of user administration. From the user's perspective, the entire authentication process takes place seamlessly and transparently.

See Also:

"RADIUS with Oracle Advanced Security"



Token Cards

Token cards provide a two-factor method of authenticating users to the database. To gain access, a user must possess the physical card, and must know the password.

Token cards (SecurID or other RADIUS-compliant cards) can improve ease of use through several different mechanisms. Some token cards dynamically display one-time passwords that are synchronized with an authentication service. The server can verify the password provided by the token card at any given time by contacting the authentication service. Other token cards have a keypad and operate on a challenge-response basis. In this case, the server offers a challenge (a number) that the user enters into a token card. The token card provides a response (another number cryptographically derived from the challenge) that the user enters and sends to the server.

Token cards provide the benefits described in Table 4-1:

Table 4-1 Benefits of Token Cards
Benefit Description

Strong authentication

To masquerade as a user, a malefactor must have the token card as well as the personal identification number (PIN) required to operate it. This is called two-factor authentication.

Ease of use

Users need only remember a PIN, instead of multiple passwords.

Ease of password management

Password management is easy because there is one token card rather than multiple passwords.

Enhanced accountability

Token cards provide a stronger authentication mechanism; users are thus more accountable for their actions.



See Also:

"Token Cards with Oracle Advanced Security"



Smart Cards

A RADIUS-compliant smart card is a credit card-like hardware device. It has memory and a processor and is read by a smart card reader located at the client workstation. Smart cards provide the benefits described in Table 4-2:

Table 4-2 Benefits of Smart Cards
Benefit Description

Increased security

Smart cards rely on two-factor authentication. The smart card can be locked, and only the user who possesses the card and knows the correct personal identification number (PIN) can unlock it.

Improved performance

Some sophisticated smart cards contain hardware-based encryption chips that can provide better throughput than software-based implementations. A smart card can also store a username.

Accessibility from any workstation

Users log in by inserting the smart card in a hardware device that reads the card and prompts the user for whatever authentication information the card requires, such as a PIN. Once the user enters the correct authentication information, the smart card generates and enters whatever other authentication information is required.

Memory

Because smart cards have memory, they can potentially store things like encryption keys, a user's private key, and even digital certificates.



See Also:

"Smart Cards with Oracle Advanced Security"



Distributed Computing Environment (DCE)

The Distributed Computing Environment (DCE) from the Open Software Foundation (OSF) is a set of integrated network services that work across multiple systems to provide a distributed environment. The network services include remote procedure calls (RPCs), directory service, security service, threads, distributed file service, diskless support, and distributed time service.

DCE is the middleware between distributed applications and the operating system and network services, and is based on a client/server model of computing. By using the services and tools that DCE provides, users can create, use, and maintain distributed applications that run across a heterogeneous environment.

See Also:

"Distributed Computing Environment (DCE) with Oracle Advanced Security"



Biometrics

Biometric solutions are another means of achieving strong authorization. In this approach, a physical characteristic such as a fingerprint or voice is used to identify and authenticate an individual.

See Also:

"Biometric Authentication with Oracle Advanced Security"



PKI and Certificate-Based Authentication

Public key infrastructure (PKI) is an industry-standard set of procedures and policies which can be used to guarantee secure information exchange. It provides encryption methods and access controls, as well as secure credentials in the form of digital certificates which can be used to authenticate users.

See Also:

"Secure Credentials: Certificate-Based Authentication in PKI"

"PKI Implementation in Oracle Advanced Security"



Proxy Authentication and Authorization

In multitier environments, such as a transaction processing monitor, it is necessary to control the security of middle-tier applications by preserving client identities and privileges through all tiers, and auditing actions taken on behalf of clients. Proxy authentication permits you to do this. For example, this feature enables the identity of someone using a Web application (also known as a proxy) to be passed through the application to the database server. This has several ramifications:

Since each middle tier can be delegated ability to authenticate and act on behalf of a specific set of users, and with a specific set of roles, proxy authentication supports a limited trust model for the middle-tier server, and avoids the problem of an all-privileged middle tier. It is also possible to give more privilege to a trusted middle tier (for example, one that is within the corporate firewall) than to a less-trusted middle tier (for example, one that is outside the firewall and thus more vulnerable to compromise). Moreover, because the identity of both middle tier and user are passed to the database through a lightweight user session, this feature makes it easier to audit the actions of users in a three-tier system, and thus improves accountability.

Figure 4-1 illustrates authentication in a multitier environment.

Figure 4-1 Proxy Authentication in a Multitier Environment Text description of scn81137.gif follows
Text description of the illustration scn81137.gif

Proxy authentication can potentially support:

One advantage of a middle tier is connection pooling, which enables 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, lightweight sessions are important. These lightweight sessions enable each user to be authenticated by a database password without the overhead of a separate database connection, and they preserve the identity of the real user through the middle tier.

See Also:

"Proxy Authentication to Ensure Three-Tier Security"

"Proxy Authentication in Oracle9i"



Single Signon

Intranet users are commonly required to use a separate password to authenticate themselves to each server they need to access in the course of their work. Multiple passwords, however, present several problems. Users have difficulty keeping track of different passwords, tend to choose poor ones, and tend to record them in obvious places. Administrators must keep track of a separate password database on each server and must address potential security problems arising from the fact that passwords are routinely and frequently sent over the network.

Single signon (SSO) does away with these problems. It enables a user to log in to different servers using a single password to obtain authenticated access to all servers she is authorized to access. It eliminates the need for multiple passwords. In addition, it simplifies management of user accounts and passwords for system administrators.

You can implement SSO in different ways, as described in the following sections:

Server-Based Single Signon

A centralized directory server can be used to store user, administration, and security information. This enables the administrator to modify information in only one location, namely, the directory. This centralization lowers the cost of administration and makes the enterprise more secure.

A directory server can be used to provide centralization of user account, user role, and password information. A database server authenticates a user with the information stored in the directory. Once authenticated, a user can access the databases configured to use enterprise user security.

Middle Tier Single Signon

Oracle9iAS Single Sign-On server is part of the Oracle9i infrastructure and provides Web-based single signon and integration with legacy applications. With single sign-on, users need maintain only a single strong user name/password account for accessing all Web applications throughout the enterprise.

Applications integrated with Oracle9iAS Single Sign-On securely delegate the user authentication process. Among other things, this enforces password rules, account lockouts based on repeated login failures, and auditing. The Single Sign-On server also has the ability to authenticate a user by means of an external repository such as LDAP or a database user repository, or by local authentication.

The first time that a user tries to access an application using Single Sign-On, the server:

In subsequent user logins, the login cookie provides the Single Sign-On Server with the user's identity and indicates that authentication has already been performed.

See Also:

"Single Sign-On Implementations in Oracle Advanced Security"

"Single Sign-On in Oracle9i Application Server"




Go to previous page Go to next page
Oracle
Copyright © 2001, 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback