Oracle8 Distributed Database Systems
Release 8.0

A58247-01

Library

Product

Contents

Index

Prev Next

4
Using the Oracle Security Server

This chapter describes how you use the Oracle Security Server to define global users and global roles in an Oracle server. Topics include

Oracle Security Server

The Oracle Security Server is a security product that enables you to centrally set up roles and users in an Oracle distributed environment. Users and roles that are defined in the Oracle Security Server can be used across multiple databases. These users and roles are called global users and global roles respectively.

Instead of using passwords to identify users, global users use certificates for identification. These certificates are based on an international standard for digital identities based on public key cryptology, and are maintained by the Oracle Security Server. Whenever a client connects to a server as a global user, the server verifies the global user's identity with the Oracle Security Server. Note that the client can be either an application connecting to a server, or a server connecting to another server using a current user database link.

A significant advantage of global users is that a password for each global user is not required in each Oracle server. Administrating passwords in each database can be troublesome, especially because certain features, like connected user database links, require the same username/password in each database. An additional advantage is of global users is that clients only "sign-on" once to retrieve a certificate from the Oracle Security Server, and then use the same certificate to access multiple databases.

Oracle Security Server Operation

Figure 4-1 illustrates the relationships between client, servers, and the Oracle Security Server. Before logging into the Oracle server, the client obtains the certificate from the Oracle Security Server. When the client logs into the database server, it sends the certificate to the database server. The database server verifies the validity of the certificate with the Oracle Security Server.

When the database server, in turn, accesses another database server using current user database links, the same authentication mechanism is used to authenticate the user in the second database.

Figure 4-1 Clients, Databases, and Oracle Security Server

Global Users

Global users allow you to keep the authentication information (login information) in the central Oracle Security Server, instead of having passwords in each database to be accessed. Also, when global user are defined, you can assign the authorization information globally. That is, you can assign global roles to global users in the central Oracle Security Server, instead of assigning the roles in each database.

Creating Global Users

There are two main steps to create global users:

Define Global Users to the Oracle Security Server

You use the Oracle Security Server Manager to define global users in the Oracle Security Server. The name of the global user in the Oracle Security Server consists of six fields of information and is based on the X.509 certificate standard. The name in the Oracle Security Server is also referred to as the distinguished name. Please see the Oracle Security Server Guide for more information on how to define global users in using the Oracle Security Server Manager.

Create Global users in the Database

You must create global users in each local database using the SQL statement

CREATE USER .... IDENTIFIED GLOBALLY AS 'external_name';

The 'external_name' must match the full distinguished name in the Oracle Security Server, and adhere to the following format:

'CN=user, L=location, ST=state, OU=unit, O=organization, C=country'

Note that there can be no conflict between local and global usernames on a database, since there can be only one user for each name. Thus, at any given database, there cannot be both a local and a global user SCOTT. If there is a global user SCOTT at the Oracle Security Server, and a local user SCOTT on a database that is NOT designated as global, these are two separate users. If SCOTT tries to login to the database, it will be handled as a purely local matter, and the Oracle Security Server will not be involved for authentication. SCOTT will be logged on as a global user, if and only if, there is a global user SCOTT at the Oracle Security Server and a global user SCOTT in the database.

Authenticating Global Users

To log into a database as a global user SCOTT, SCOTT must authenticate himself directly with the Oracle Security Server. SCOTT provides the distinguished name to a tool provided by Oracle Security Server, which returns a certificate (and a private key) from the Oracle Security Server. SCOTT can log into any database using "CONNECT /" if, and only if,

Global Roles

Instead of granting roles to each user in each database, global roles allow you to assign authorization information to (global) users across multiple databases. When a global user logs into a database, the global roles assigned to that user will be automatically available. Although global roles are assigned to global users in the Oracle Security Server, the privileges associated with each global role are defined in each Oracle server. Therefore, the privileges associated with a specific global role can differ between databases based on the privileges assigned to the global role in each database.

Creating Global Roles

Like global users, global roles must be

Defining Global Roles in the Oracle Security Server

You define global roles in the Oracle Security Server using the Oracle Security Server Manager. In the Oracle Security Server Manager, global roles are also known as Server Roles. Please see the Oracle Security Server Guide for more information on how to define global users in using the Oracle Security Server Manager.

Creating Global Roles in the Database

You must create global roles in each local Oracle server using the SQL statement:

CREATE ROLE .... IDENTIFIED GLOBALLY;

Interaction between local roles and global roles is similar to that between local and global users. Even if a local role has a name identical to an authorization listed at the central authority, if it has not been defined locally as a global role, it will not be interpreted as such.

Granting Privileges to Global Roles

In each database, you can grant system privileges, object privileges, and local roles to a global role using the GRANT statement. You cannot grant external roles to global roles. You cannot grant global roles to global roles in the database.

Global roles can only be "assigned" to enterprise roles in the Oracle Security Server. See also the Oracle8 Reference for information on granting privileges to roles, granting roles to roles, and granting roles to users.

Assigning Global Roles to Global Users

You must assign global roles to global users in the Oracle Security Server. Also, you can not assign global roles to local users or local roles. See the Oracle Security Server Guide for information on how to assign global roles to global users.

Enterprise Roles

The Oracle Security Server Manager also allows the security administrator to create enterprise roles. Just as global roles are a collection of privileges, enterprise roles are a collection of global roles.

You can use enterprise roles to grant a global user access to a selected group of global roles (and, therefore, the privileges they comprise) across a system of distributed databases. While global users and global roles must be defined both at the local database and within the Oracle Security Server, enterprise roles are defined only within the Oracle Security Server.

See the Oracle Security Server Guide for detailed information about defining enterprise roles within the Oracle Security Server.

Trusting Other Databases

By default, each database defined in the Oracle Security Server trusts the other databases defined in the Oracle Security Server. However, you can specify that each database trust only some databases, or you can specify that it not trust any other databases.

If a database does not trust another database, database links that use the Oracle Security Server (that is, current user database links) cannot be used to establish a connection between the two databases.

Trust Between more than Two Databases

Trust between databases is not transitive. That is, if database A trusts database B, and database B trusts database C, database C does not necessarily trust database A. This means that if a particular (global) user session, initiated on database A, must connect to database B using the Oracle Security Server, and database B in turn must connect to database C (for the same session that initiated on database A and using the Oracle Security Server), database B will not be able to connect to database C because database C does not trust database A. Note that (global) user sessions initiated from database B, will be able to connect to database C.

In general, if a global user session requires a chain of database links, each database to be added to the chain will examine all databases in the chain so far. If there is a single database in the chain that cannot be trusted, the connection will be refused.

Administering Trust

The package DBMS_DISTRIBUTED_TRUST_ADMIN is used to define the databases that are (not) to be trusted. The package contains four procedures:

The data dictionary view TRUSTED_SERVERS can be used to see which databases are (not) trusted by the database.

Note: When a server-to-server connection uses a database link that does not use the Oracle Security Server for authentication, for example a fixed user database link or a connected user database link that is initiated from a non-global user, the connection can not be refused based on the trust.

Example

If you haven't yet used the package DBMS_DISTRIBUTED_TRUST_ADMIN to change trust, the default is that all servers defined in the Oracle Security Server are considered trusted:

SELECT * FROM TRUSTED_SERVERS;
TRUST      NAME                                                                            
--------- ---------------------
Trusted   All                                                                             

1 row selected.

Since all servers are currently trusted, you can execute the DENY_SERVER procedure and specify that a particular server is not trusted:

EXECUTE DBMS_DISTRIBUTED_TRUST_ADMIN.DENY_SERVER
                           ('SALES.US.AMERICAS.ACME_AUTO.COM');

Statement processed.

SELECT * FROM TRUSTED_SERVERS;

TRUST       NAME                                                                            
--------- -----------------------------------------------
Untrusted SALES.US.AMERICAS.ACME_AUTO.COM 

1 row selected

By executing the DENY_ALL procedure, you can choose to not trust any database server:

EXECUTE DBMS_DISTRIBUTED_TRUST_ADMIN.DENY_ALL; 

Statement processed.

SELECT * FROM TRUSTED_SERVERS;

TRUST       NAME                                                                            
--------- -----------------------------------------------
Untrusted All                                                                             

1 row selected.

The ALLOW_SERVER procedure can be used to specify that one particular database is to be trusted:

EXECUTE 
DBMS_DISTRIBUTED_TRUST_ADMIN.ALLOW_SERVER 
                            ('SALES.US.AMERICAS.ACME_AUTO.COM');

Statement processed.

SELECT * FROM TRUSTED_SERVERS;

TRUST       NAME                                                                            
--------- ------------------------------------------------
Trusted   SALES.US.AMERICAS.ACME_AUTO.COM

1 row selected.

It is important to know whether all servers are trusted or not trusted. Trusting a particular server with the ALLOW_SERVER procedure will not have any impact if the database already trusts all databases or if that database is already trusted. Similarly, denying a particular server with the DENY_SERVER procedure will not have any effect if the database already doesn't trust any database or if that database is already untrusted.

Also note that the procedures DENY_ALL and ALLOW_ALL will delete all entries (i.e. server names) that are explicitly allowed or denied using the ALLOW_SERVER procedure or DENY_SERVER procedure respectively.

Note: To execute the DBMS_DISTRIBUTED_TRUST_ADMIN package, the EXECUTE_CATALOG_ROLE role must be granted to the DBA. To select from the view TRUSTED_SERVERS, the SELECT_CATALOG_ROLE role must be granted to the DBA.

Additional Information: For reference information about this package, see Appendix D, "DBMS_DISTRIBUTED_TRUST_ADMIN Package Reference".




Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index