|Oracle® Application Server for DRDA User's Guide
12c Release 1 (12.1) for Linux x86-64
|PDF · Mobi · ePub|
This chapter discusses security and storage issues associated with Oracle Application Server for DRDA.
This chapter contains these topics:
Oracle Application Server for DRDA uses the security and authorization models of the Oracle Database; this ensures correct SQL access to user data.
DRDA specifies two primary authorization models:
OWNER. They are specified as attribute of the package,
REQUESTER model, currently logged-in user is the authorization control.
REQUESTER model is also called Dynamic SQL Rules, and it is used for executing the SQL that is constructed at runtime. This is the security model that Oracle Database implements for SQL access.
OWNER model, a stored
USERID (package owner,
PKGOWNID) instantiates a different
USERID for the duration of the statement execution.
OWNER model is also called Static SQL Rules, and it is used for pre-bound SQL within the package. Oracle Database does not implement an equivalent security model.
Because Oracle Database only implements one security model, all SQL within a package, both stored and dynamically created, is executed under the Dynamic SQL Rules model. This does not override the instantiation modes of any PL/SQL objects created with the
AUTHID DEFINER attribute.
See Oracle® Database PL/SQL Language Referencee for details about
DRDA requires that user authentication (ACCSEC(SECMEC), SECCHK) be performed before any access to the database (ACCRDB) may be performed.
DRDA provides two types of services for authentication: dedicated use, and multiplexed use.
Under dedicated use, the AS provides access to a single, dedicated database, without an option to connect to another database. The rdbnam passed later in the ACCRDB must match the target database name; otherwise, the session access fails with an RDBAFLRM message.
In this mode, the ACCSEC does not require the rdbnam instance variable to perform authentication because there is no choice to be made between databases. Thus, the AS is free to make a session association with the single database at the time of ACCSEC processing, and to verify that the requested security mechanism (SECMEC) is available. When the SECCHK command is sent, the initial database session is maintained and full authentication is performed.
This mode must be used with older ARs that do not support multiplexed servers. If the AR supplies the rdbnam in this mode, it must be validated against the connected database.
Under multiplexed mode, the AS provides access to many databases at the same time. In this mode, the rdbnam instance variable in the ACCSEC is required to validate the requested security mechanism. The AS connects to the requested database for security validation. When the SECCHK command is sent, the initial database session is maintained and full authentication is performed.
This mode is supported with newer ARs, which supply the rdbnam as part of the ACCSEC. If the AR does not supply the rdbnam in the ACCSEC in this mode, it generates an error and an RDBAFLRM response is sent to the ACCSEC.
Oracle Application Server for DRDA supports the following security mechanisms:
EUSRIDPWD – Encrypted User ID and Password Mechanism
EUSRIDNWPWD – Encrypted User ID, Password, and New Password Mechanism
USRIDPWD – User ID and Password Mechanism
USRIDNWPWD – User ID, Password, and New Password Mechanism
USRENCPWD – User ID and Password Encrypted Mechanism
After the security mechanisms are verified as accessible, the actual security authorization (SECCHK) can proceed.
Oracle Application Server for DRDA uses the following two roles:
DRDAAS_ADMIN_ROLE role allows access to and use of the
DBMS_DRDAAS_ADMIN package. It is a DBA-level privilege specific to Oracle Application Server for DRDA. Administrators who manage remote DRDA access to the Oracle database must be granted this role.
DRDAAS_USER_ROLE role permits an Oracle Application Server for DRDA user access to the
DBMS_DRDAAS package for the following purposes:
For binding a DRDA package
For permitting read access to Oracle Application Server for DRDA package resource tables
For package execution
Without the privileges of the
DRDAAS_USER_ROLE role, Oracle Application Server for DRDA user is unable to execute DRDA packages to which they have granted access.
Oracle Application Server for DRDA users have allocated storage named
SYSIBM. This is implemented by the
SYSIBM tablespace and
All tables, views and packages supplied and used by the Application Server for management and support functions are in the tablespace
SYSIBM. This tablespace must be created before installing Oracle Application Server for DRDA support packages. An example of how to create the
SYSIBM tablespace is the
catdrdaas.sql script supplied with the product. See the listing for catdrdaas.sql in Appendix A, "Scripts for Creating and Maintaining the Environment for Oracle Application Server for DRDA".
create tablespace SYSIBM datafile 'sysibm01.dbf' size 70M reuse extent management local segment space management auto online;
All tables, views, and packages supplied and used by Oracle Application Server for DRDA are under the user schema
SYSIBM. As part of the installation of Oracle Application Server for DRDA packages and tables, this user id is created as a locked account, and is set to use the
SYSIBM tablespace for its storage.