Oracle9i Security New Features

Strong Internet Security

Page 1
 Objectives

After this lesson, you should be able to:

• Understand proxy authentication enhancements
• Demonstrate a knowledge of PKI enhancements
• Understand Web Single Sign-on new features
• Understand the role of Oracle Internet Directory in
web-based Single Sign-On deployments

Page 2
 Security Myths

• Myth: Hackers cause most security breaches.

• Fact: 80% of data loss is to insiders.

• Myth: Encryption makes you secure.

• Fact: Security includes access control, data
integrity, encryption, and auditing.

• Myth: Firewalls make you secure.

• Fact: 40% of Internet break-ins occur where there
is a firewall in place.

Page 3
 Oracle Answers to Security Questions

Is an order read or
• Privacy of
Communications modified in transit?
Network encryption

• Sensitive Data Is your credit card #

Storage stored in clear?
Encryption of stored data

• Know your Users Who is accessing the

data from the web?
Strong authentication

Page 4
 Oracle Answers to Security Questions
(Continued)
• Granular Access Can a customer see only
Control her own order?
Virtual Private Database

Can you support 100,000s of

• Scalability
users?
Oracle Internet Directory
integration
Is it easy to use for users &
• Ease of Use
administrators?
Oracle Internet Directory
integration

Page 5
 Oracle9i Proxy Authentication
Enhancements
• Expanded protocol support
– thick JDBC, OCI for database and enterprise user
proxy
– OCI, thick JDBC, thin JDBC, ultra JDBC for
application user proxy
• Expanded credential proxy (DN, certificate)
• Expanded user model (enterprise user, database
user, application user)
• Pulls three tier security together with Oracle
Internet Directory

Proxy Authentication Enhancements

The introduction of n-tier authentication (also known as Proxy Authentication)
provides several benefits:
• Eliminates super-privileged middle tiers
• Preserves user identity throughout the application
• Provides scalability through lightweight OCI and JDBC connections
• Provides accountability through audit of connections on behalf of the real user

Page 6
 Oracle9i Secure Application Role

• In a three-tier system, secure application role can

ensure that the session is initiated through a
middle tier
Users are forced to access the data through the proper
Application
• Secure Application Role is implemented through a
package
• The package can do the proper validation to
ensure that the required conditions are in place
before the ROLE is set

Secure Application Role

In Oracle8i, we introduced the idea of application context, essentially allowing each PL/SQL package
to have their space of session variables. Application role in Oracle9i is utilizes a similar concept of
authentication to allow users to enable role based on PL/SQL packages, and without supplying a
password. This feature is a significant proxy authentication enhancement.
The SET ROLE command ensures that only the trusted package is consulted. The package can do the
desired validation to ensure that the appropriate conditions are in place before the ROLE is set.
For example in a three tier system in which proxy authentication is used, the package can ensure that
the PROXY_USER attribute of the user session (using 'USERENV' naming context) is set. The result:
users who connect to the database by proxy (through the application) have the role enabled and thus
access the data while users who connect directly to database do not get the role enabled and thus see no
data through privileges granted to the role.

Page 7
 Secure Application Role

CREATE ROLE approle USING hr.secrole

• Package does any desired validation

– Proxy authentication allows verification of middle
tier connection:

SYS_CONTEXT(‘USERENV’, ‘PROXY_USER’)

• Other useful session information accessible

through USERENV
– IP_ADDRESS - where user connected from
– AUTHENTICATION_DATA - includes X.509 certificate
if certificate proxied

Secure Application Role

The secure application role can be granted globally or locally. That is, the secure application role can
be granted to the user by creating the appropriate entry in Oracle Internet Directory (part of the
Enterprise User Security feature of Oracle Advanced Security). The role can also be granted locally for
database users.

Page 8
 Public Key Infrastructure

PKI Includes the use of:

• X.509 Digital Certificates
• Public-Key Pair and Private-Key Pair
• Secure Sockets Layer (SSL) Protocol
• Certificate Authority - the trust provider

What is PKI ?
PKI is a standards-based, interoperable trusted certificate technology that scales to
the Internet and millions of users. A trusted certificate is a third-party identity that is
trusted. The trust is used when an identity is being validated as the entity it claims
to be.. Typically, the certificate authorities you trust issue user certificates. If there
are several levels of trusted certificates, a trusted certificate at a lower level in the
certificate chain does not need to have all its higher level certificates re-verified.
Oracle uses a non-Oracle Certificate Authority such as Entrust, VeriSign, or
Baltimore in its PKI implementation. These Certificate Authorities support Oracle
Internet Directory as repositories for publishing CA information like certificates and
certificate revocation lists. Authentication and secure session key management is
accomplished using Secure Sockets Layer (SSL).

Page 9
 Public Key Infrastructure Tools

Oracle9i PKI Implementation:

• Components:
– Oracle Advanced Security
– Oracle Internet Directory
• Management Tools:
– Oracle Wallet Manager
– Oracle Login Assistant
– Oracle Enterprise Security Manager

Public Key Infrastructure Tools

Authentication systems based on public key cryptography systems issue digital certificates to user
clients, which use them to authenticate directly to servers in the enterprise without direct involvement
of an authentication server. Oracle provides a public key infrastructure (PKI) for using public keys and
certificates. Features include:
• Oracle Wallet Manager 3.0, a standalone Java application used to manage and edit the security
credentials in Oracle wallets. Oracle wallets are data structures that contain a user private key, a
user certificate, and a set of trust points (the list of root certificates the user trusts).
• Oracle Internet Directory provides a central repository for authentication information such as
certificates and revocation lists, wallets, policies, etc.
• Oracle Enterprise Login Assistant is used to open and close wallets, to update centrally managed
wallets and passwords in Oracle Internet Directory, and to enable or disable secure SSL
connections.

Page 10
 Oracle Wallet Enhancements

• Support of additional PKI standards

• Storage of Oracle Wallets in Oracle Internet
Directory
• Strong wallet encryption
• Multiple certificates support
• Enhanced wallet password management
• Oracle Wallets can be stored in any Windows
based registry

Oracle Wallet Enhancements

Oracle Wallet Manager supports multiple certificates (and multiple private keys) in each wallet.
Password management includes minimum password length, require alphanumeric character mix, etc.
Password management policy can be derived from the OID server.
Oracle wallets can be stored in Windows Registry in addition to the file system. Oracle Wallet
Manager and Enterprise Login Assistant can read wallets from the file system or from the Windows
System Registry. Benefits include:
•Enhanced security
•Easier administration of users and their credentials

Page 11
 Additional PKI Interoperability

• X.509 certificates are stored in PKCS#12 containers

making the Oracle wallet interoperable with
Netscape Communicator 4.x and Microsoft Internet
Explorer 5.x
• PKCS#12 is operating system independent,
allowing hot-desked users and downloadable
wallets

PKI Interoperability
Since PKCS#12 is a PKI standard for credential storage, Oracle can now support downloadable,
machine independent wallets. The same wallet and PKI credentials can be used for the browser and for
Oracle Wallet (requires export/import in PKCS#12 format).
This added functionality enables interoperability with browsers such as Netscape and Internet Explorer.
Now that Oracle Wallets are compatible with browser wallets, customer no longer have to purchase
two different sets of PKI credentials.

Page 12
 Oracle Internet Directory Support for
Wallets
• Oracle Wallet Manager can upload and retrieve
wallets from Oracle Internet Directory

• Storing the wallets in a centralized LDAP directory

allows users to access applications from any
location ensuring reliable user authentication

OID Support for Wallets

Oracle Enterprise Security Manager creates user wallets as part of the user enrollment process. The
wallet is stored in a directory like OID. Oracle Wallet Manager can upload wallets and retrieve them
from Oracle Internet Directory. Storing the wallet in a centralized directory lets users access them from
multiple locations or devices, ensuring consistent and reliable user authentication while providing
centralized wallet management throughout the wallet life cycle.
Oracle Advanced Security is tightly integrated with OID, which can act as a gateway to synchronize
data with other LDAPv3 compliant directories if needed.

Page 13
 Oracle Wallet Enhancements

Multiple Certificate Support

• Oracle Wallet Manager now supports multiple
certificates for different Oracle PKI applications
including:
– SSL
– S/MIME signing and encryption
– Code Signing
• A single user Wallet can now contain multiple
certificates and private key pairs used for different
applications
• Wallet encryption using 3DES (Triple DES), makes
the wallets much more resistant to "hacking"

Oracle Wallet Enhancements

Oracle Wallet Manager supports multiple certificates for a single digital entity, where each certificate
can be used for a set of Oracle PKI certificate usages— but the same certificate cannot be used for all
such usages. There must be a one-to-one mapping between certificate requests and certificates. The
same certificate request cannot be used to obtain multiple certificates, installed in the same wallet.
Oracle Wallet Manager uses X.509 V3 extension KeyUsage to define Oracle PKI certificate usages.
KeyUsage Values

Value Usage
0 digitalSignature
1 nonRepudiation
2 keyEncipherment
3 dataEncipherment
4 keyAgreement
5 keyCertSign
6 cRLSign
7 encipherOnly
8 decipherOnly

Page 14
Oracle Wallet Enhancements (continued)
When installing a certificate (user certificate, trusted certificate), Oracle Wallet Manager maps the
KeyUsage extension values to Oracle PKI certificate usages.
You should obtain certificates from the certificate authority with the correct KeyUsage value for the
required Oracle PKI certificate usage. A single wallet can contain multiple key pairs for the same
usage. Each certificate can support multiple Oracle PKI certificate usages. Oracle PKI applications use
the first certificate containing the required PKI certificate usage.

Page 15
 Wallet Password Management

From Oracle Wallet Manager (OWM):

Oracle Wallet Password Enhancements

Enhanced wallet password management can enforce policy guidelines such as:
• Minimum password length
• Maximum password length unlimited
• Alphanumeric character mix required

Page 16
 Multiple Wallet Formats

Oracle Advanced Security supports multiple

wallet formats, including:
• Oracle Wallets
• Entrust profiles
• Microsoft Certificate Store

Supported Wallet Formats

In addition to Oracle Wallets, Oracle Advanced Security also supports Entrust profiles and Microsoft
Certificate Store.

Page 17
 Oracle Wallets and Windows

• Oracle Wallets can be stored in the user profile

area on any Windows system
– Windows 95 and 98
– Windows ME
– Windows NT
– Windows 2000
• Oracle Wallet Manager can create and manage
wallets in the system registry
• Oracle Enterprise Login Assistant can read wallets
stored in the system registry
• Security and ease of administration is enhanced

Oracle Wallets and the Windows Registry

Oracle Wallet Manager lets you optionally store multiple Oracle wallets in the user profile area of the
Microsoft Windows System Registry (for Windows 95/98/ME/NT 4.0/2000), or in a Windows file
management system. Storing your wallets in the registry provides the following benefits:
• Better Access Control - Wallets stored in the user profile area of the registry are only accessible by
the associated user. User access controls for the system thus become, by extension, access controls for
the wallets. In addition, when a user logs out of a system, access to that user’s wallets is effectively
precluded.
• Easier Administration - Since wallets are associated with specific user profiles, no permissions need
to be managed, and the wallets stored in the profile are automatically deleted when the user profile is
deleted. Oracle Wallet Manager can be used to create and manage the wallets in the registry, and the
wallets are accessible by Oracle Enterprise Login Assistant as well.
• Improved Security - Because the wallets are imbedded in the registry, the wallets associated with a
particular user profile are transparent to all other users. Viewed in combination with better access
control and easier administration, this amounts to an additional security layer for Oracle wallets.
Options Supported:
• Open wallet from the Registry
• Save wallet to the Registry
• Save As to a different Registry location
• Delete wallet from the Registry
• Open wallet from the file system and save it to the Registry
• Open wallet from the Registry and save it to the file system

Page 18
 Single Sign-On

• Users no longer need to remember different

passwords for every application they access
• Two-Tier Single Sign-On
– Kerberos
– PKI-based
– Entrust integration
– DCE
• Oracle Login Server provides web-based single
sign-on and integration with legacy applications
using passwords for authentication
• Hosting environment security is enhanced through
single sign-on
• Login Server is a component of Oracle Portal 3.0 in
Oracle9i Application Server 1.0.2

Single Sign-On
Oracle Advanced Security single sign-on authenticates the user once upon initial connection, with
strong authentication occurring transparently in subsequent connections to other databases or services.
Using single sign-on, users can access multiple accounts and applications with a single password.
Oracle Advanced Security supports many forms of two-tier single sign-on with strong authentication,
including:
• Kerberos
• PKI-based
• Entrust integration
• DCE
Single Sign-On capabilities are extended to web based applications and external or legacy applications
through Oracle Login Server. Oracle Advanced Security also provides SSL-based single sign-on for
Oracle users by integrating with Oracle Internet Directory. The combination of integrated directory
services through OID and Oracle’s PKI implementation enable SSL-based single sign-on to Oracle9i
databases. Single sign-on lets users be authenticated once, with subsequent connections relying on the
user’s digital certificate. In addition this integration model provides a single point of password
management throughout the enterprise.

Page 19
 Single Sign-On For Web Applications

How Oracle provides single sign-on capabilities for

web applications:
• Centralized login server that authenticates the user
and sets SSO credentials
• API tells partner applications how to communicate
with the login server
– Crypto functions
– Parsing instructions for the url or identification
cookie
• Authentication information is propagated from
Login Server to applications with identification or
URL token
• Provide Single Sign-On across different web sites
by performing user mapping among the web
servers

Page 20
 Single Sign-On Integration

Oracle9i Single Sign-On is designed to work with:

• Partner applications
– Applications which have been modified to accept
authentication credentials from the central login
server
• External Applications
– Applications that cannot be modified, preventing
them from replacing their existing authentication
scheme.
• Portlets
– The output of various Portlets is combined by the
portal to produce a composite web page to be
returned to the user

Single Sign-On Integration

The login server is able to authenticate the user credentials against multiple kinds of password stores
that are configured by the administrator. Fundamentally, the interfaces that the login server uses to
verify the user's name against the password will be the same but the underlying adapters will be
different. These password stores can be either existing database accounts, table lookups, or other
external repositories like Oracle Internet Directory (OID).
If it is existing database accounts then the login server will verify if it can bind to the database with the
user id and password specified. The rest of the information needed for user validation and
management, such as last password change, will be stored as a part of other tables in the schema.
In the second case, the login server looks up against some tables in its schema containing user
credentials. The incoming password is one-way hashed and compared against the entry in the table.
The third case involves the login server to look up the user credentials against any external repository
like OID. LDAP servers typically being central repositories for the enterprise would store user
credentials. In such a case the login server would invoke some LDAP C-API to bind to LDAP to verify
credentials and then fetch some attributes.

Page 21
 Single Sign-On With Partner Applications
5. Login Server redirects
4. Login server authenticates user to Partner App A with
password and returns a URL Application A encrypted token
cookie
Application B
6. Partner App A sets Oracle
App A cookie
2. App A redirects Internet
user to Login Server Directory
1, 6 2, 5
3. Login server displays
username/password web page
4
1. User accesses App A which Username
determines user is not
authenticated (no cookie)
Password

Login
Server
User 3, 4

Single Sign-On With Partner Applications

In practice, the user points the browser to a portal providing access to all the organization’s SSO
enabled (partner) applications. The user is then challenged by the login server for the proper
credentials. If the credentials are authenticated, the login server redirects the user back to the
application along with a URL cookie containing some application specific SSO information.

Page 22
 Single Sign-On With External Applications

• In the case of foreign applications the user would

still authenticate to the login server
• The login server retrieves the username and
password from Oracle Internet Directory for each
application
• For each application that the user access
subsequently, the login server would retrieve the
user's password for that application and pass this
information over

External Applications
The user is responsible for maintaining the contents of his or her entries in the wallet. The
administrator for the would be responsible for providing for mapping information for foreign
applications.

Page 23
 Directory Service Integration

Oracle Directory Integration Platform

• Provides synchronization of various directories
with Oracle Internet Directory
– Allows the creation of "Metadirectories"
• Allows outside Metadirectory vendors to create
OID connectivity agents
• Provides consistent, up-to-date information for
users and applications
• Provides a single point of access to all directory
data through standards-based clients like Web
browsers or email clients
• Provides a central point of administration of all
enterprise directories

Oracle Directory Integration Platform

The Oracle Directory Integration platform enables you to synchronize various
directories with Oracle Internet Directory. It also makes it easier for third party
metadirectory vendors and developers to develop and deploy their own connectivity
agents.
Metadirectories synchronize information between all enterprise directories, forming
one virtual directory. It centralizes administration, thereby reducing administrative
costs and it ensures that data is consistent and up-to-date across the enterprise.
Oracle Directory Integration platform enables you to:
• Import data from connected directories into Oracle Internet Directory, either all
at once or incrementally
• Export data from Oracle Internet Directory into connected directories, either all
at once or incrementally
• Synchronize all or part of the data in a connected directory with Oracle Internet
Directory
Synchronization is bi-directional. Changes in Oracle Internet Directory are exported
to connected directories, and changes in connected directories are imported into
Oracle Internet Directory.

Page 24
 Oracle Directory Integration Server

The integration server is the central component of

Oracle Directory Integration platform performing:
• Scheduling
• Mapping
• Error handling

Oracle Directory Integration Server

The Oracle directory integration server is a multithreaded daemon server process. It
is the central component of Oracle Directory Integration platform. It performs:
• Scheduling— Running a directory integration agent at a time you specify
• Mapping— Executing rules for converting data between connected directories
and Oracle Internet Directory
• Error handling
Multiple integration servers can exist on a different systems. Multiple instances of
directory integration server may be run concurrently on the same computer. Each
instance has a configuration set entry listing the agents the Oracle directory
integration server instance is to run.
Directory Integration Agents
A directory integration agent is a program that synchronizes data between Oracle
Internet Directory and connected directories. When it synchronizes the data, it does
one or more of the following:
• Exports changes out of Oracle Internet Directory
• Imports changes into a connected directory
• Exports changes out of a connected directory
• Imports changes into Oracle Internet Directory

Page 25
Oracle Directory Integration Server (continued)
Depending on how it is deployed in the Oracle Directory Integration platform, an
agent can be either a partner agent or an external agent. Partner agents run under the
control of the Oracle directory integration server meaning that the Oracle directory
integration server performs scheduling, data mapping, and error handling for them.
Before deploying a partner agent, you register it in Oracle Internet Directory. This
registration involves creating a directory integration profile in the directory. To
create the profile, you can use either Oracle Directory Manager or command-line
tools.
A partner agent uses either an import file or an export file to exchange data between
a connected directory and Oracle Internet Directory. At execution time, they may
use additional agent configuration information stored in Oracle Internet Directory.
Unlike partner agents, external agents are independent of the Oracle directory
integration server. The Oracle directory integration server performs neither
scheduling nor data mapping for them. External agents do not need to register with
Oracle Internet Directory.
Typically, external agents are used when a third party metadirectory solution is
integrated with the platform. The third party metadirectory solution uses its own
metadirectory engine to perform mapping and scheduling.

Page 26
 Summary

In this lesson, you should have learned about:

• Understand proxy authentication enhancements
• Demonstrate a knowledge of PKI enhancements
• Understand Web Single Sign-on new features
• Understand the role of Oracle Internet Directory in
web-based Single Sign-On deployments

Page 27
Oracle 9i Security New Features

Oracle Data Server Security

Page 1
 Objectives

After this lesson, you should be able to:

• Discuss Enterprise User Security
• Describe Virtual Private Database enhancements
• Explain the concept of Fine Grained Auditing
• Explain why “connect internal” has been de-
supported

Page 2
 Enterprise User Security

• Password authenticated enterprise users

• Passwords managed through Oracle Enterprise
Login Assistant (ELA)
• Eliminate need for client side wallets and Secure
Socket Layer processing

Enterprise User Management Enhancements

Enterprise User Security is an Oracle Advanced Security feature. Oracle9i
complements certificate based authentication with password based authentication for
enterprise users. Enterprise user credentials and authorizations can be stored in
Oracle Internet Directory. This includes the username and encrypted password
verifiers, enterprise roles, and mappings to individual schemas on each database to
which the user has access rights.
Note: The installation and use of both SSL and Oracle wallets continue to be a
requirement on the server side— to establish a secure channel between the database
and Oracle Internet Directory.

Page 3
 Enterprise User Security Enhancements

Benefits:
• Integrate enterprise user management with proxy
authentication
• Manage both password-based and SSL-
authenticated users in a directory
• Improved ease of use
• Reduced processing overhead
• Simplified Enterprise user setup and
administration
• Backward compatibility for non-SSL clients
• Changes affect the server side only so older (pre
Oracle9i) clients are interoperable

Benefits of Enterprise User Security Enhancements

Since enterprise users now require only one username and password (stored in OID)
to access multiple databases, useability is improved. With the elimination of bi-
directional certificate matching, processing overhead is reduced and performance
improves.
Security administrators can set up enterprise users to access multiple databases with
the same username and password. In addition, there is no requirement to install SSL
on the client side, and no requirement to setup and maintain client-side wallets
thereby simplifying enterprise user administration.
Since there is no requirement for SSL or Oracle wallets on the client, all prior
Oracle clients can function as enterprise users provided that they are password
authenticated users. In addition, Oracle Enterprise Login Assistant lets users change
passwords and utilize single sign-on whether they use Release 9i clients, Release 8i
clients, or Release 8.0 or earlier versions.

Page 4
 Oracle Enterprise Login Assistant

• Client-side tool used to authenticate users to the

enterprise
• It can authenticate users to Oracle Internet
Directory and download an Oracle wallet from the
directory
• It can decrypt the wallet and establish an SSL
connection to all PKI-enabled applications without
requiring additional passwords
• Can update the directory password (OID only) and
other related passwords stored in the directory
• It can upload an Oracle Wallet to the directory.

Oracle Enterprise Login Assistant

Oracle Enterprise Login Assistant is a client-side tool used to authenticate users to
the enterprise. It can authenticate users to a directory service like OID, and
download an Oracle wallet from the directory. It can also decrypt the wallet and let
users establish a seamless SSL connection to all PKI-enabled applications and
databases within the enterprise— without requiring additional passwords. Enterprise
Login Assistant can update the directory password (OID only) and other related
passwords stored in the directory, and it can also upload an Oracle Wallet to the
directory.

Page 5
 Enterprise User Security Management
Store jsmith, scott, sarah,
OWM Oracle their passwords and
or ELA Internet roles
jsmith Directory
single sign-on LD
W W AP
/SS
8i or 9i client Orac L
Web le Ne
Application t/SSL
scott/tiger
single sign-on Login Server
with password Oracle9i
9i client W
t
SQL*Plus le Ne W = Wallet
Orac
sarah/tiger
single password
Any (7.3, 8.0, 8i or 9i)
Oracle client

Enterprise User Security Management

Oracle Wallet Manager can upload and retrieve wallets from Oracle Internet
Directory. Storing wallets in a directory store lets users access them from multiple
locations or devices, ensuring consistent and reliable user authentication— while
providing centralized wallet management throughout the wallet life cycle. To
prevent accidental over-write of functional wallets, only wallets containing a
functional certificate can be uploaded.
Oracle Wallet Manager requires that enterprise users are already defined and
configured in the directory, to be able to upload or download wallets. If a directory
contains Oracle8i (or prior) users, they are automatically upgraded to use the wallet
upload/download feature— upon first use. Oracle Wallet Manager downloads a user
wallet using a simple password based connection to the directory. However, for
uploads it uses an SSL connection if the open wallet contains a certificate with SSL
Oracle PKI certificate usage.
Oracle Enterprise Login Assistant can open and close wallets, update centrally
managed wallets and passwords in OID, and to enable or disable secure SSL
connections.

Page 6
 Update Passwords
Store jsmith, scott, sarah,
OWM or ELA
Oracle their passwords and roles
jsmith Internet
Update locally Directory
W W
8i or 9i client

ELA Oracle Data

Server
Oracle Data
scott/tiger1 Server
Update on OID Oracle9i
9i client W
W
Browser

sarah/tiger2
Update on OID ELA Change password
Any (7.3, 8.0, 8i or 9i) Servlet on directory
Oracle client

Client Compatibility – Enterprise Users

The example above shows how older clients can participate in enterprise user
security, as well as how users on any client can update his passwords on the
directory using ASO (and specifically Enterprise Login Assistant). Oracle9i
password-authenticated enterprise users can use their local copy of ELA, which is
Oracle Internet Directory-enabled, to change their password. Other clients can use a
browser to connect to the Enterprise Login Assistant Servlet, which is used to
change the user’s password on the directory.

Page 7
 CONNECT INTERNAL De-support

• Connecting AS SYSDBA will connect you as a DBA

user just as CONNECT INTERNAL would
• If you connect using SQLPlUS /NOLOG, replace all
your CONNECT INTERNAL commands with CONNECT
/ AS SYSDBA
Remember, Server Manager is also de-supported in
Oracle9i
• SQL*Plus supports the following syntax:
– SQLPLUS / AS SYSDBA
– SQLPLUS / AS SYSOPER
– SQLPLUS USERNAME/PASSWORD AS SYSDBA
– SQLPLUS USERNAME/PASSWORD AS SYSOPER

De-Support of CONNECT INTERNAL

Why is CONNECT INTERNAL being de-supported in Oracle9i ?
• To limit the methods by which an Oracle user can connect as a DBA user type
• To maintain homogeneity across all Oracle product platforms
• To provide stricter accountability of DBA user type connections

Page 8
 Virtual Private Database Enhancements

• Security policy administration is provided by Oracle

Policy Manager
– Oracle Policy Manager - performs policy management
for VPD policies and Oracle Label Security
• Global Application Context
– Secure application context can be shared among
multiple sessions
– Java API to application context
– Supports application user models
• Partitioned Fine Grained Access Control
– VPD enhancements for multi application environment
– "Per application" policy group allows completely
different policies for different applications

Virtual Private Database Enhancements

Oracle9i offers improved management of VPD policies through Oracle Policy
Manager, an easy-to-use graphical user interface accessed through Oracle Enterprise
Manager.
Oracle9i provides enhanced ability to partition security policy enforcement by
application, thus facilitating VPD deployment. Oracle9i enables partitioning of
Virtual Private Database through policy groups and a driving application context. A
driving application context securely determines which application is accessing data,
and policy groups facilitate managing the policies which apply by application.
Oracle9i also supports default policy groups, which always apply to data access.
Partitioned application context facilities application development using VPD,
because development groups no longer need to collude; applications can have
different security policies based upon their individual application needs.
Many web-based applications use connection pooling to achieve high scalability and
thereby support hundreds of thousands of users. These applications set up and reuse
connections instead of having different sessions for each user. Oracle9i VPD
capabilities facilitate connection pooling by allowing multiple connections to access
one or more global application contexts, instead of setting up an application context
for each user session.

Page 9
 Partitioned Fine Grained Access Control

• Support of application driven security policies

• Policy groups allow association of policies with
specific applications
• Default policy provides access control conditions
that always apply
• By defining an application context to drive the
enforcement of a set of policies to the base
objects, each application can now implement a
private set of security policies
• Different policies apply, depending on which
application accesses data
• Development groups do not have to collude on
security policies

Partitioned Fine Grained Access Control

In current state of application architecture where different products are tightly
integrated with each user, meaning sharing the same base tables and privileges, the
AND properties of fine grained access control policies at the base table can be
cumbersome because it requires certain sharing of information between products so
that policies written for one product may appropriately generate predicates for other
products. Therefore, for ease of applying fine grained access control when multiple
applications are sharing the same data, the idea of partitioned fine grained access
control is introduced to allow application driven security policies.
For example, in case of a hosting environment, let’s say company A uses this feature
to host the BENEFIT table for company B and company C. The table is to be
accessed by two different applications, HR and FINANCE, each wanting to enforce
different security policies. HR application authorizes users based on ranking in the
company, and FINANCE application authorizes users based on department. In
Oracle8i, integrating these two policies into the BENEFIT table would require joint
development of policies between the two products groups, not really a feasible
option if two products come from rival companies. Even if this is a configuration
option it would be a nightmare to consider all possible cases. By defining an
application context to drive the enforcement of a particular set of policies to the base
objects, each application can now implement a private set of security policies.

Page 10
 Policy Groups

• Used to distinguish policies between different

applications
• The administrator will designate an application
context called a driving context, to indicate the
policy group in effect
• When the tables/views are accessed, the fine
grained access control engine will look up the
driving context to determine the policy group in
effect
The feature will enforce all the associated policies that
belong to the policy group

Policy Groups
With the partitioning of fine grained access control policies, administrators can
specify which policy group the policy falls into when adding policy to a table/view
using the ADD_POLICY_TO_GROUP interface. We are predefining a policy
group named SYS_DEFAULT. Policies defined in this policy group for a particular
table/view will always be executed along with the policy group specified by the
driving context. For backward compatibility purpose, all Oracle8i fine grained
access control policies have been migrated into this default policy group to maintain
the idea of global policies.

Page 11
 Partitioned Fine Grained Access Control

Order Entry Inventory

policy group policy group

Default policy

ERS
ORD

Partitioned Fine Grained Access Control- An Example

In Oracle8i all policies that applied to an object were automatically "ANDed"
together, which made application development very difficult especially for hosted
applications. In Oracle9i, a simpler approach is taken.
In the above example, an order entry clerk connects to the Orders table through the
Order Entry application. Inside the database, a driving context sets the policy group
to 'Order Entry' (which enforces access control on customer number and region).
There is also a default policy group that enforces per company data separation (since
this is a hosted application).
An inventory manager connects to the Inventory application which accesses the
same Orders table. The driving context sets the Inventory Manager's policy group to
Inventory, which enforces access control based on part number. There is also a
default policy group that enforces per company data separation (since this is a
hosted application).
Each user accesses different data, based on entirely different policies. The security
enforcement is transparent to the user; e.g. each may issue the SQL statement
'SELECT * from ORDERS' but entirely different data sets are returned.

Page 12
 Global Application Context

User A 3. Application
2. Application
determines creates Gold,
that User A is 4. Application sets Silver, Bronze
1. User A Gold global contexts
client_identifier to
connects Gold

Application
Application
Server
Server Oracle9i
7. Application resets
client_identifier to
Silver
6. Application
5. User B determines
User B
connects User B is Silver

Global Application Context

Application user proxy authentication can be used with global application context
for additional flexibility and high performance in building eBusiness applications.
For example, suppose a web-based application that provides information to business
partners has three types of users: Gold, Silver, and Bronze, representing different
levels of information available. Instead of each user having his own session with
individual application contexts set up, the application could set up global application
contexts for Gold, Silver or Bronze and use the client identifier to point the session
at the correct context, in order to retrieve the appropriate type of data. The
application need only initialize the three global contexts once, and use the client
identifier to access the correct application context to limit data access.
This provides performance improvements through session reuse and through
accessing global application contexts set up once, instead of having to initialize
application contexts for each session individually.
Note that the 'client identifier' can be an actual application username, also. In this
case, the application would set up a global application context for a user and use the
client_identifier - e.g. 'Jane' to access the global application context. Suppose that
Jane now accesses a different application, and Ajit connects. The application can set
up a global (rather than a per session) context, change the client_identifier on the
session to be 'Ajit' and now reference Ajit's global application context. When Jane
reconnects, the session can be reused by Jane.
Application user proxy authentication with global application context is well-suited
for web-based applications in which you want to reuse sessions.

Page 13
 Global Application Context

• Simplifies connection pooling by enabling multiple

connections to access one or more global
application contexts
• Global application contexts provide additional
flexibility for web-based applications to use Virtual
Private Database
• Performance is enhanced by reusing common
application contexts between multiple sessions
• Application user proxy authentication can be used
with global application context for better flexibility
and performance when building eBusiness apps

Global Application Context

Oracle9i VPD capabilities facilitate connection pooling by allowing multiple
connections to access one or more global application contexts, instead of setting up
an application context for each user session. Global application contexts provide
additional flexibility for web-based applications to use Virtual Private Database, as
well as enhanced performance through reuse of common application contexts among
multiple sessions instead of setting up per-session application contexts.
Application user proxy authentication can be used with global application context
for additional flexibility and high performance in building eBusiness applications.
This provides performance improvements through session reuse, and through
accessing global application contexts set up once, instead of having to initialize
application contexts for each session individually.
In order to decide the driving context for the current session to enforce fine grain
access control, the middle tier needs to set the application context for the session .
The Global Context allows the middle tier to store the various application context
definitions in a central place in the instance (SGA) and apply the context to a user
session at session creation time. This then becomes that session’s driving context.
This will greatly reduce the user session (application context setup) setup time in a
application connection pooling environment.
To support the application managed session pooling by middle tier applications, the
DBMS_SESSION interface for managing application context is also enhanced to
add a client identifier for each application context so that application context can be
managed globally while each client will see only their assigned application context.

Page 14
 Managing Application Context

A set of interfaces has been added to the

DBMS_SESSION package to manage application
context in client sessions
• SET_CONTEXT
• CLEAR_CONTEXT
• SET_IDENTIFIER
• CLEAR_IDENTIFIER

Managing Application Context

The middle tier application server can use SET_CONTEXT to set application
context for a specific client id. Then, when assigning a database connection to
process the client request, the application server needs to issue a SET_IDENTIFIER
to denote the id of the application session. From then on, every time the client
invokes SYS_CONTEXT, only the context that was associated with the set
identifier is returned.

Page 15
 Application Context Applied

For a n-tier application, the scenario is as follows:

1. Administrator creates the global context
namespace by issuing:
CREATE CONTEXT hr USING hr.init ACCESSED GLOBALLY;

2. HR application server starts up and establishes

multiple connections to the HR database as user
APPSMGR
3. User SCOTT logs on to the HR application server
4. AS authenticates SCOTT into the application
5. AS assigns a temporary session id ( or simply use
the application user id), 12345, for this connection

Page 16
 Application Context Applied

6. The session id is returned to SCOTT’s browser as

part of a cookie or maintained by the application
server
7. The application server initializes application
context for this client calling hr.init package,
which issues:

DBMS_SESSION.SET_CONTEXT('hr', 'id', 'scott', 'APPSMGR', 12345 );

DBMS_SESSION.SET_CONTEXT('hr', 'dept', 'sales', 'APPSMGR', 12345 );

8. The application server assigns a database

connection to this session, and initializes the
session by issuing:
DBMS_SESSION.SET_IDENTIFIER( 12345 );

Application Context Applied

The syntax for using DBMS_SESSION.SET_CONTEXT is:
DBMS_SESSION.SET_CONTEXT (
namespace VARCHAR2,
attribute VARCHAR2,
value VARCHAR2,
username VARCHAR2,
client_id VARCHAR2 );

Parameter Description
namespace The namespace of the application context to be set
attribute The attribute of the application context to be set
value The value of the application context to be set
username The username attribute of the application context
client_id The client_id attribute of the application context

The syntax for DBMS_SESSION.SET_IDENTIFIER is:

DBMS_SESSION.SET_IDENTIFIER (
VARCHAR2);
Where client_id is the application-specific identifier of the database session.

Page 17
 Application Context Applied

9. All SYS_CONTEXT calls within this database

session will only return application context values
belonging to the client session only; for example,
SYS_CONTEXT(’hr’,’id’) will return ’scott’;
10.When done with the session, the application
server can issue the command below to clean up
the client identity.

DBMS_SESSION.CLEAR_IDENTIFIER ( );

Application Context Applied – Continued

Note that even if another database user ADAMS had logged into the database, he
can not access the global context set by AS because application server has specified
that only the application with logged in user APPSMGR can see the global context.
If AS has used:
DBMS_SESSION.SET_CONTEXT( ’hr’, ’id’, ’scott’, NULL , 12345 );
DBMS_SESSION.SET_CONTEXT( ’hr’, ’dept’, ’sales’, NULL , 12345 );
Then, any user session, with client id set to 12345, can see the global context. This
is useful in the context that different users can share the same context. The users
should be aware of the security implication of different settings of global context.
Basically, NULL in username means any user can access the global context; and
NULL client id in the global context means only session with uninitialized client id
can access the global context.
This feature has a negligible effect on the performance because this only requires an
additional hash table lookup of the driving context. Abuse of this feature could
cause concurrency problems, though, because of the nature of synchronization
access to the shared application context.

Page 18
 DBMS_OBFUSCATION_TOOLKIT
Enhancements

• FIPS-140 certified random number generator for

secure key generation incorporated in the GetKey
function
• Secure random number generation makes
implementation much more secure

DBMS_OBFUSCATION_TOOLKIT Enhancements
The DBMS_OBFUSCATION_TOOLKIT packages require an encryption key as an
attribute. If keys are weak (that is, easy to guess or predictable), it makes encryption
much easier to break through cryptanalysis. Time of day, serial number of machines
and the like are all predictable and thus cannot be used as random numbers for
cryptographic keys. DBMS_RANDOM in particular cannot be used as a secure
random number generator since a given seed (input) will always produce the same
output. In Oracle 9i, a Federal Information Processing Standard (FIPS) -140
certified random number generator (GetKey) for secure key generation Secure
random number generation makes implementation much easier
While key management is still programmatic, having a secure random number
generator means that the solution is much more likely to be secure against
cryptanalysis as long as keys are stored securely. That said, it would be difficult to
recover data using a brute force attack if the keys are securely stored and randomly
generated.

Page 19
 Fine Grained Auditing

• A tool to provide extensible intrusion detection,

capturing the SQL statement, not the retrieved data
• This auditing policy is based on simple user defined
SQL predicates on tables as conditions for selective
auditing
• Attach audit policy to table or view with WHERE
condition on SELECT statements
• Oracle executes a user-defined audit event handler
using autonomous transactions to process the
event
• An AUDIT COLUMN feature is provided to reduce
false audit conditions

Fine Grained Auditing

Auditing in the DBMS is often used to monitor data access. Audit records are
essential in proving the violation of access rights. Currently in Oracle, a fixed set of
facts (userid, timestamp, object name...etc) are recorded in the audit trail.
Previously, audit options could only be set to monitor access of privileges or objects.
There was no support for getting more specific information about the environment
or query results, nor any mechanism to specify audit conditions in order to minimize
false audits. In many cases, these access logs are insufficient to reconstruct the
event, or even to determine whether access rights have been violated.
The new value based auditing mechanism addresses the issues of more granular
level of auditing. In general, the new auditing policy is to based on simple user
defined SQL predicates on table objects as conditions for selective auditing.
In addition to value based, there are also cases where the administrators are only
interested in whether a certain column is being referenced or accessed. In this
regard, the idea of audit column is supported, that is, whenever a column is selected
in any part of a DML statement, Oracle will audit the query.

Page 20
 Fine-grained Auditing

Audit Policy

...
WHERE SALARY >500000
Not Audited AUDIT COLUMN = SALARY

SELECT NAME,
ADDRESS FROM EMP Audit Records

SELECT NAME,
SELECT NAME, SALARY SALARY FROM EMP
FROM EMP WHERE WHERE NAME =
NAME=ELLISON ELLISON,
<timestamp>,
EES <username>, etc.
LOY
EMP

Fine-Grained Auditing Specifics

Fine-grained auditing is available only on SELECT statements with a WHERE
clause, and for one audit column only.
The triggering event above was not only that the user accessed employee records for
which salaries are greater than $500K, but that the salary was actually returned to
the user. This limits the audit information actually logged and of course ensures
relevancy. A record is written to the audit trail that includes the complete SQL
statement the user submitted, a timestamp, username and other information.
Fine grained auditing does not automatically capture the statements returned to the
user; however, you may be able to use fine-grained auditing in conjunction with
Flashback Query to recreate the records returned to the user.
Fine-grained auditing can function as an intrusion detection system for the database.
For example, a developer could add an event handle to a policy to page an
administrator if certain events occur. Non-SQL access is not audited, for example if
you use direct path load, which bypasses the SQL layer of the database, the audit
condition is not triggered.

Page 21
 Fine Grained Auditing Concepts

• The PL/SQL package DBMS_FGA is provided to

administer value-based audit policies
• The security administrator uses DBMS_FGA to
create an audit policy on the table(s) in question
• If any of the rows returned from a query matches
the audit condition the database inserts an audit
event entry into the audit trail
– The audit event entry includes username, SQL text,
bind variable, policy name, session id, timestamp,
and other attributes
– The involved rows are referred to as interested rows
• Administrators can define audit event handlers, to
process the event, such as sending an alert page
to the administrator.

FGA Concepts
Fine grained auditing allows the monitoring of data access based on content. More
importantly, the monitoring does not depend on how it is done. A built-in audit
mechanism into the database that users can not bypass is essential. Oracle DBMS
has already provided triggers capability for potentially monitoring DML actions
such as INSERT/UPDATE/DELETE. However, monitoring on SELECT is costly
and may not work for all cases. In addition, users may want to define their own alert
action in addition to just inserting an audit record into the audit trail. This feature
provides an extensible interface to audit SELECT/UPDATE/INSERT/DELETE on
tables and views.
Use DBMS_FGA PL/SQL package interface to apply policies to tables or views
• ADD_POLICY
• DROP_POLICY
• ENABLE_POLICY
• DISABLE_POLICY

Page 22
 Fine Grained Auditing

Adding a policy:

DBMS_FGA.ADD_POLICY(
object_schema => 'hr',
object_name => 'emp',
policy_name => 'chk_hr_emp',
audit_condition => 'dept = "SALES"',
audit_column => 'salary');

Adding a Policy
To audit SELECT’s on table HR.EMP to monitor any query that accesses the salary
column of the employee records that belong to sales department, the administrator
can issue the SQL statement above to initiate the auditing.

Page 23
 Triggering Audit Events

• The following SQL statements will cause the

database to log an audit event record:
SELECT count(*) FROM hr.emp WHERE dept = 'SALES‘ \
and salary > 1000000;

Or

SELECT salary FROM hr.emp WHERE dept = 'SALES';

• The following SQL statement will NOT log an audit

event record:
SELECT salary FROM hr.emp WHERE dept = 'ENG';

Audit Events
In general, fine-grained auditing policy is based on simple user-defined SQL
predicates (where clause) on table objects as conditions for selective auditing.
During fetching, whenever policy conditions are met for a returning row, the query
is audited. Later, Oracle executes user-defined audit event handlers using
autonomous transactions to process the event.
Fine-grained auditing can be implemented in user applications using the
DBMS_FGA package or by using database triggers.

Page 24
 Fine Grained Auditing

Create an audit event handler:

CREATE PROCEDURE sec.log_id (schema varchar2, table varchar2, \

policy varchar2) AS
luser varchar2(30);
sql varchar2(2000);
time date;
BEGIN
UTIL_ALERT_PAGER(HR,EMP,CK_HR_EMP);-- send an alert note to
-- my pager
END;

Page 25
 Fine Grained Auditing

Add a policy with an audit event handler:

/* add the policy */
DBMS_FGA.ADD_POLICY(
object_schema => ’hr’,
object_name => ’emp’,
policy_name => ’chk_hr_emp’,
audit_condition => ’dept = ’’SALES’’ ’,
audit_column => ’salary’,
handler_schema => ’sec’,
handler_module => ’log_id’ ,
enable => TRUE);

After the fetch of the first interested row, the event is

logged and the audit function sec.log_id is fired.

Add a Policy With an Audit Event Handler

In the example above, when the first interested row is fetched, the audit event record
will be recorded and stored in the new format of FGA_ AUD$ which has columns for
SQL text, bind variables and policy name and the audit function sec.log_id is fired.

Page 26
 Security of Default Accounts

• Security by default
– Locking of most default accounts on installation
– SYS and SYSTEM to be locked in future release
• Rationale
– Hackers love unlocked, privileged accounts with
default passwords
– Fewer unlocked default accounts equates to better
security

Locking Default Accounts

Hackers love breaking into databases using unchanged default accounts and
passwords because it is so easy! There are 17 of them in Oracle8i. In
Oracle9i they numbered 32 at last count.
To make the database more secure, most default accounts are locked . The
SCOTT/TIGER account is unlocked so that the packaged demos will work.
Once users inspect the demos, we recommend that SCOTT be locked also
because there are grants to PUBLIC <by default> that can be put to ill use.

Page 27
 Default Account Security

• Unlock default accounts only when you need to use

them

ALTER USER ctxsys ACCOUNT UNLOCK

• Change default passwords on default accounts

ALTER USER ctxsys IDENTIFIED BY #twU8=+qksu

Default Account Security

Passwords should be changed regularly as a general security principle. When you
unlock default accounts, change the password! Make the passwords sufficiently
complex, of sufficient length, and with numeric as well as alphabetic characters.
There are many password-cracking tools available. L0phtcrack, a hacker favorite,
cracks passwords with amazing rapidity - less than four hours for even a very
complex password. Many of these cracking tools use a language dictionary, so avoid
using recognizable words or names in your passwords. Random character mixes are
best. Please keep that in mind when choosing passwords.

Page 28
 Summary

After finishing this lesson, you should be able to:

• Discuss Enterprise User Security
• Describe Virtual Private Database enhancements
• Explain the concept of Fine Grained Auditing
• Explain why “connect internal” has been de-
supported

Page 29