15.3 What's in the OSS? The OSS is comprised of several components that use underlying protocols to enable its wide assortment of security features. The features the OSS provides are: We have already discussed, in a general way, the meaning and function of each of these security approaches. This section examines the OSS structure and what protocols are used to support the features. 15.3.1 The OSS Architecture The OSS is made up of the following components: The person who interacts with and manages the tool is referred to as the security administrator. As we've discussed earlier in the book, the security administrator at a site might be a DBA or someone whose basic job is as a security manager or system administrator. In other words, the security administrator does not have to be a DBA to work with the OSS toolset. Each piece of the OSS the repository, the Manager, the Authentication Adapter, and the security administrator himself or herself combines to comprise a certificate authority. The OSS toolset can be used with both Oracle7 from version 7.3.2 forward and Oracle8. 15.3.1.1 The OSS Repository As with some other Oracle products, such as the Oracle Enterprise Manager (OEM) and the Oracle Recovery Manger (RMAN), the Oracle Security Server requires an area of a database in which information can be stored about encrypted private keys as well as certification authorities. The actions supported by the OSS Repository are: -
The generation and storage of certificates requested by the security administrator or manager -
Responses to queries about the status of certificates (whether they have expired or have been revoked ) -
The storage of information about Oracle Application Server certificate requests As with the other Oracle repositories, you must carefully select the database in which the OSS Repository will reside, as well as what procedures will be used to protect and back up the repository. When you install the OSS, the tablespace and associated datafiles to house the repository and the repository itself are created, along with two users: oracle_security_service and oracle_security_service_admin . After installation of the OSS product, the OSS code is located in the $ORACLE_HOME/Oss directory. You should examine the script NZDOCRT.SQL , which is used to create the OSS repository. Since this script creates the tablespace in which the OSS repository will reside, you might want to change the disk location or size used as the creation defaults. At the very least, you want to look at this script just to ensure you know what it is doing. Make sure the version of the RDBMS is 8.0.4 or higher and the version of Net8 (formerly SQL*Net) is 8.0.4 or higher. When setting up the OSS Repository, take the same steps you'd follow to establish any other OSS user. In other words, to create a usable OSS repository, you must set up a SQL*Net connection listing in the SQLNET.ORA file of the database that will house the repository. You'll also use the osslogin tool to install a wallet for the repository. By following these steps, you'll enable a secure environment from which the OSS can function. 15.3.1.2 The OSS Manager As we will see in the later section, "Installing the OSS," the OSS Manager is composed of software that lets you interact with the OSS through the Oracle Enterprise Manager product set. The OSS Manager is used to perform these tasks : -
Administer the OSS repository -
Define global users and global roles -
Define and maintain information about identities -
Track authorizations granted to identities 15.3.1.3 The OSS Authentication Adapter The OSS Authentication Adapter is used by Net8 clients , Oracle7 databases, and/or Oracle8 databases to enable interaction with the OSS Repository. Using OSS Authentication Adapters, processes can deal with certificates of authority in various ways: -
Request certificates -
Obtain certificates -
Use certificates -
Query the status of a certificate to verify if the certificate has expired, has been revoked, or is valid -
Mutually authenticate themselves and retrieve role information to enable the process to perform work Authentication occurs using OSS Authentication Adapters. All communication between the various components of the OSS and other entities is done using SQL*Net and/or Net8. 15.3.2 Protocols and Algorithms Oracle Corporation has taken advantage of several industry-standard protocols to provide various forms of security within the OSS: -
For authentication, a version of the Security Exchange Mechanism (SKEME) protocol developed by Hugo Krawczyk is used. -
For certificates of authority, the X.509 version 1 protocol is used. -
For public/private key pairs, RSA Data Security's TIPEM library function (currently a 512-bit version) is used. -
For digital signatures, an RSA cryptographic algorithm and RSA's Message Digest 5 (MD5) one-way hash function algorithm (using functions in the RSA TIPEM and BSAFE security tools) is used. The RSA algorithm is the 512-bit US-exportable version; MD5 produces a 128-bit hash value. The OSS allows you to define several forms of subjects: to enhance single sign-on, distributed authentication of entities to each other, and central authorization of users performing global tasks. Let's take a moment to look at what single sign-on can provide for you. As a DBA, you might have several accounts on different machines from which you administer several different databases per machine. You currently have to remember a separate username and password for each machine and each database account. With the implementation of a single sign-on mechanism, you will only have to remember and use one username and password to access all of your machines and databases. In the next chapter, we'll examine more closely the use of the web and security. For now, just note that the OSS can play a vital part in enhancing web-based security. 15.3.2.1 Global users and global roles with OSS Suppose you are an accounting clerk in your company and you need to be able to perform the same list of tasks across a group of databases on different machines. You can log on to each database, specifying your username and password each time, and perform your tasks, but this can be very cumbersome especially if your password expires on different machines at different times. You might end up having to keep track of several passwords for several different databases on several different machines. Wouldn't it be useful if you only had to log on once to a central location and obtain the ability to connect to each database on any machine without having to use another username and password? If your DBA creates a global user for you and creates a global role that will give you the privileges you need to perform your set of tasks, you can do just that. You obtain a certificate of authority (a single set of credentials) from the OSS and then access each database to perform your work. Your certificate enables you to connect to the databases without having to use a separate username and password for each connection. The OSS keeps track of the privileges you have been granted for each database by tracking the global roles that have been created and granted to you across the entire group of machines. Although the OSS will track the global roles, the DBA still must create the global roles in each of the databases in order to give the global roles meaning to the individual, local database servers. 15.3.2.2 Creating a global user and global role To create a global user, the DBA issues a command in the form: CREATE USER username IDENTIFIED GLOBALLY AS 'C=country,O=organization,OU=organization_unit,ST=state,L=locality,CN=user'; Notice that the definition includes the same values, in the same exact order, as the distinguished name described earlier in this chapter (see the "Distinguished names " section). Therefore, a global user created for the distinguished name we created for mary would look like this: CREATE USER mary IDENTIFIED GLOBALLY AS 'C=US,O=MyCompany,OU=MyDept,ST=VA,L=Vienna,CN=mary' Now, let's give mary some privileges so she can perform her tasks. The global role for the user mary will be "marys_role", and the syntax to create the global role would look like this: CREATE ROLE marys_role IDENTIFIED GLOBALLY; "Ah," you say, "but you haven't really given mary privileges to do anything!" and you would be correct. Next, we have to grant the appropriate privileges to the global role so mary can perform work. We would certainly need to give mary the ability to connect to the databases. So, we might say: GRANT create session TO marys_role; We might also want the mary account to be able to input data, update information, and delete data from the employees table. We would issue the command: GRANT select, insert, update, delete ON employees TO marys_role; Note that, prior to this script, when we listed duties we wanted the mary account to be able to perform, the ability to "look at" (SELECT) the data was not mentioned. However, in Oracle8, the SELECT privilege must be granted if the user is to be able to perform any of the other duties against a table or view. Correspondingly, we would need to create the role "marys_role" in each database mary will be working with, and grant the same privileges in each database in order for mary to be able to perform tasks. | 
