When an Oracle userid is defined as IDENTIFIED EXTERNALLY it means the user is authenticated by operating system facilities rather than by Oracle. On z/OS, this mechanism works in one of two ways:
■ The user logs on to the operating system and is authenticated by normal operating system security. When the user runs an Oracle tool or application, it logs on to Oracle with "/" (a single forward slash) instead of specifying an Oracle userid and password. Oracle takes the user's z/OS userid as the Oracle userid (possibly with a prefix, specified as the OS_AUTHENT_PREFIX
init.ora file parameter). This means the user can access Oracle only with z/OS userids for which the password is known. This technique is normally used only when the user is running on the same z/OS system as the Oracle server being accessed. Although it can be enabled for use over Oracle Net,
Note: Be aware that for backup and restore operations, the EDM address space does not open or access the associated Oracle database (VSAM LDS) files. Those files are accessed only in the Oracle server address space.
Authorizing Oracle Logon
doing so is not considered secure because the server cannot guarantee that the associated userid was authenticated.
■ The user runs an Oracle tool or application that logs on to the Oracle server with an explicit userid/password. The verification of the userid and password is controlled by the LOGON_AUTH database region parameter, which can specify one of three verification choices:
No SAF check. If a user defined to Oracle as IDENTIFIED EXTERNALLY attempts to logon with an explicit userid/password, the logon is rejected.
Built-in SAF check. This built-in SAF check verifies that the userid and
password that are provided on the logon are valid. The user need not be logged on to z/OS with the same userid and in fact may be running on a non-z/OS platform (connecting via Oracle Net). The Oracle userid must be defined to the z/OS security subsystem and the given password must be correct for the logon to succeed. A RACROUTE VERIFY function is performed by the OSDI code, but no logon exit is called in this case. SAF interfaces with any security manager that you have installed (IBM's RACF, CA's Top Secret or ACF2, an internally developed security manager, or another third-party security manager). This SAF check is designed to work with virtually any security manager and eliminates the need for an external logon exit, unless you want to modify the normal RACROUTE VERIFY of a userid and password.
External logon exit. This method calls an external, dynamically loaded logon exit. Oracle Corporation supplies a sample logon exit (which does what the built-in SAF check does), or you can write your own. This exit performs the actions that you specify and then returns success or failure of the validation.
The built-in SAF check and the external logon exit are called only for users that are IDENTIFIED EXTERNALLY. These checks are not performed for a user who is defined to Oracle (IDENTIFIED BY <password>), because these users can be resolved internally within Oracle.
The type of validation done for users that are IDENTIFIED EXTERNALLY is indicated in the OSDI service parameters. A single parameter controls this validation. The syntax is:
Note: The supplied sample logon exit and the built-in SAF check are functionally equivalent. Unless site-specific changes to the sample logon exit are needed, the built-in SAF check should be used because it is more efficient.
Authorizing Oracle Logon
LOGON_AUTH (auth) where auth is:
NONE - explicit specification of userid/password not allowed SAF - perform built-in SAF check
exitname - call logon exit
The default (if nothing is specified) is NONE.
For example:
LOGON_AUTH(NONE) LOGON_AUTH(SAF) LOGON_AUTH(RACFSMPO)
The logon exit must reside in the STEPLIB or JOBLIB concatenation or in the linklist, and it must be in an authorized library.
A sample user logon exit is provided in Oracle SRCLIB library member
RACFSMPO. It uses the z/OS SAF interface to invoke the z/OS security manager.
If the z/OS security manager does not support the SAF interface, then the calls to RACROUTE in the exit must be replaced with the equivalent calls appropriate for the z/OS security manager.
The calling sequence for the logon exit uses standard z/OS assembler calling conventions. R15 is the entry point, R14 is the return address, R13 points to a standard 72-byte save area, and R1 is the address of a parameter list. The parameter list consists of a list of addresses of each parameter (all values are passed by
reference, not by value), and the last parameter has the high-order bit set.
When returning, R15 should be set to 0 to indicate a successful verification of the userid and password that were supplied, and should be set to any nonzero value to indicate any type of failure (four would be an appropriate value).
The exit is called in 31-bit addressing mode, supervisor state, storage protection key 7, and in an authorized address space. The exit will be running in TCB mode with no locks held and with no ARRs, FRRs, or EUT-style FRRs set. The exit is called in primary addressing mode with HASN=PASN=SASN (home, not cross memory mode).
The logon exit should be fully reentrant code.
The parameter list that is passed contains pointers to the following parameters, all of which are input only:
Authorizing Oracle Logon
The only output of the logon exit is the R15 return code. No other value that is passed in the parameter list should be modified except the first one.
The first parameter is a 4096-byte work area that is set to all x'00' before every call to the logon exit. The logon exit can use this storage for anything that it needs. It should not be freed.
Table 9–3 Input-Only Parameters
Field Type/Length Description
work area char/4k set to all x'00' before every call to the exit userid char/1+ userid to be validated (number of bytes varies) userid length bin/2 length of userid
password char/1+ password to be validated (number of bytes varies) password length bin/2 length of password
z/OS jobname char/8 z/OS jobname from JOB card of client ASID bin/2 address space id of client address space OSDI session id bin/4 a unique OSDI session id
OS username char/8 the operating system username (batch, TSO, CICS, and IMS only)
terminal name char/8 terminal name
program name char/8 program name
RACF group name char/8 RACF group name
connection type char/8 connection type (BATCH, TSO, CICS, IMS, TCP/IP, VTAM) to indicate environment of client
JES jobid char/8 JES job identifier (such as JOB08237)
job card entry time bin/4 entry (submission) time of job. Binary hundredths of a second since midnight
job card entry date packed/4 entry (submission) date of job. Packed decimal 0CYYDDDF, where C=0 FOR 19, C=1 FOR 20, YY=year, DDD=day number within the year (Jan 1=1)
job card accounting info char/145 from jobcard network data (high bit
set in parameter list)
char/2+ variable length NIV data (refer to Chapter 10,
"Oracle SMF Data")
Authorizing Oracle Logon
The logon exit can do any of the following:
■ call a security manager (SAF calls, RACF, Top Secret, ACF2, and so forth)
■ get and free storage using the STORAGE macro (the exit must keep track of all acquired storage and must make certain to free it before exiting)
■ call SMF to write SMF records
■ call WTO to write messages to the console
The logon exit should not do anything that would cause it to wait for any significant period of time (more than one tenth of a second, for example). Avoid opening data sets, writing to the operator with a reply (WTOR), and creating enqueues.
Any resources that are acquired in the logon exit must be freed before it returns.
There is no cleanup call made to the logon exit, so any resources that are not released will accumulate in the address space and could eventually cause resource shortages.