6
Administering Enterprise User Security

This chapter describes the elements that make up a strong enterprise user management facility.

Introduction

Most organizations, whether eBusinesses or not, face daunting obstacles in user management. Users within an organization often have far too many user accounts, a problem exacerbated by the growth in web-based self-service applications. Every other week, users have a new user account and password to remember. Organizations that want data access and accountability by user do not want the administrative nightmare of managing users in each database a user accesses.

This problem is compounded for web-facing, eBusiness applications. An organization opening its mission-critical systems to partners and customers does not want to create an account for each partner in each database the partner accesses, yet privilege and accountability for each partner is highly desired. Powerful, enterprise user management tools are necessary to meet these needs.

Enterprise Privilege Administration

An inherent challenge of any distributed system, including three-tier systems, is that common application information is often fragmented across the enterprise, leading to data that is redundant, inconsistent, and expensive to manage. Directories are being viewed by an increasing number of Oracle and third-party products as the best mechanism to make enterprise information available to multiple systems within an enterprise. Directories also make it possible for organizations to access or share certain types of information over the Internet, for example, through a virtual private network. The trend toward directories has been accelerated by the recent growth of the Lightweight Directory Access Protocol (LDAP).

A specific type of enterprise information that is commonly proposed for storage in a directory is privilege and access control information. Both user privileges, represented as roles, and object constraints, represented as Access Control Lists (ACLs) listing those users who may access an object, may be stored in a directory.

Directory information that specifies users' privileges or access attributes is sensitive, since unauthorized modification of this information can result in unauthorized granting or denial of privileges or access to users. A directory that maintains this information on behalf of the enterprise must ensure that only authorized system security administrators can modify privilege or access information maintained in the directory.

"Enterprise User Security Features of Oracle Advanced Security"

Shared Schemas

A shared schema (also known as a schema-independent user) is a database user whose identity is maintained in a central LDAP repository. When a schema-independent user connects to the database, the database queries the directory to determine if the user is registered there, and if so, to what database schema the user should be mapped, and what roles the user should obtain.

Suppose, for example, that there are 500 users of an application, who require access to data on several database servers in the enterprise. Instead of maintaining 500 different user accounts on each database, Oracle allows the system administrator to create a single shared schema (such as HRAPPUSER for the HR application), with appropriate privileges, on each database, and then create 500 enterprise users in an Oracle Internet Directory. When they connect to any specific database, these users are mapped to the appropriate schema on the database (such as HRAPPUSER), and inherit the privileges associated with the schema, as well as any additional privileges that are associated with the roles granted to them in the directory. Although these users share a common schema, individual schema-independent users' identities are associated with their sessions by the database, and are used for access control or auditing purposes. Once created, these user accounts in LDAP can be used within multiple applications, as well.

The shared schema user feature has a number of benefits. It reduces the administrative burden associated with managing users in an enterprise, and allows effective management of much larger communities of users than was previously possible. Moreover, it can provide a mechanism for integrating user account and privilege management across tiers in a multitier system, as long as the middle tier also supports management of user identities and privileges in the directory. In such a system, new users and their privileges can be registered once in a directory, and this gives them appropriate access to the middle tier as well as any databases in the enterprise that they need to access. In the future, it should be possible to build three-tier systems (such as web storefronts) in which new users can register themselves with a web server, and the web server then creates an entry for these users in the directory, giving them access to information in appropriate databases that pertain to them.

"Shared Schemas with Oracle Internet Directory"

Password-Authenticated Enterprise Users

To reduce processing overhead and the administrative burden, it is desirable to have password-based authentication for enterprise users. Further, enterprise users should be able to use a single enterprise username and password to connect to multiple databases, if desired. This feature is particularly useful for large user communities accessing multiple applications.

Enterprise Roles

If you have centralized management of user-related information in an LDAP-compliant directory service, you can store and manage enterprise roles to determine enterprise users' access privileges on databases. An enterprise role is a directory structure that contains global roles on multiple databases, and that can be granted to enterprise users.

Multitier Authentication and Authorization

In applications that use a heavy middle tier, such as a transaction processing monitor, it is important to be able to preserve the identity of the client connecting to the middle tier. Client identities and privileges must be preserved and audited through all tiers.

Single Sign-On

A typical user on a corporate intranet has access to a multitude of client applications. Such a user must remember a username and password for each application being accessed. From the user's perspective, keeping in mind a myriad of username and password combinations, and having to re-enter them (for authentication) each time a different application is accessed, is not efficient. This may lead to the user maintaining just one username and password for all the applications to which access has been granted. This is generally not recommended as sound security practice, because a hacker can choose a number of attack points within such a framework.

From the application's perspective, such a framework requires the maintenance of each user's username and password store. This leads to password store redundancy and non-communication between applications due to the lack of transferable information regarding the user's roles and privileges (which may be granted on an enterprise-wide basis).

With single sign-on technology, a user can enter a unique username and password once. These are subsequently used to automatically authenticate the user to a number of different client applications without the user having to re-enter a username, password, or both. The user's roles and privileges are propagated from one application to another such that he or she is appropriately privileged in the application being accessed.

6 Administering Enterprise User Security