Release 8.0
A58247-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Distributed Database Systems Release 8.0 A58247-01 |
|
This chapter describes how you use the Oracle Security Server to define global users and global roles in an Oracle server. Topics include
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.
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.
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.
There are two main steps to create global users:
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.
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.
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,
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.
Like global users, global roles must be
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.
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.
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.
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.
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.
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 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.
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.
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".
