AIM

TA.080 APPLICATION SECURITY

ARCHITECTURE
<Company Long Name>
<Subject>

Author: <Author>
Creation Date: June 11, 1999
Last Updated: June 14, 1999
Document Ref: <Document Reference Number>
Version: DRAFT 1A

Approvals:

<Approver 1>

<Approver 2>
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Document Control

Change Record
3

Date Author Version Change Reference

11-Jun-99 <Author> Draft 1a No Previous Document

Reviewers

Name Position

Distribution

Copy Name Location

No.
1
Library Master Project Library
2 Project Manager
3
4

Note To Holders:

If you receive an electronic copy of this document and print it out, please
write your name on the equivalent of the cover page, for document
control purposes.

If you receive a hard copy of this document, please write your name on
the front cover, for document control purposes.

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Contents

Document Control............................................................................................

Introduction......................................................................................................
Purpose......................................................................................................
Basic Business Needs................................................................................
Application and Database Security Architecture............................................
Background................................................................................................
Application Security Mapping..........................................................................

Application Security Design............................................................................

Trusted Services........................................................................................
Application Security Configuration..................................................................

Database Security Design...............................................................................

Database Security Configuration....................................................................

Open and Closed Issues for this Deliverable..................................................

Open Issues................................................................................................
Closed Issues.............................................................................................

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Introduction

Purpose

The purpose of the Application Security Architecture document is to

describe the approach being taken to secure access to information and
key systems for <Company Long Name> within the scope of the <Project
Name>.

It is envisioned that this deliverable will be useful summary of the

Application Security Architecture for the following processes in the
<Project Name> project:

· Application and Technical Architecture

· Module Design and Build (especially Interface modules)
· Business Requirements Mapping

However, any individual in the <Project Name> project team should have
access to the deliverable for reference purposes.

Basic Business Needs

The following areas were covered during the development of this

Application Security Architecture:

· a study of the base capabilities of the applications and overall

planned environment as they relate to access and information
security
· development of the business requirements for access and
information security including the need for trusted services for
payment, bill presentation and business to business transmittals

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Application and Database Security Architecture

Background

There are generally three approaches to provide application data level

security in Oracle ApplicationsÔ. The first and easiest method is to use
the data partitioning features that exist in the applications to achieve the
data security. For example, General Ledger supports multiple sets of
books and data can be secured by set of books in the vanilla application.
This then enables legal entities to have their GL data secured from other
entities.

The next easiest method is to prevent users from having access to forms,
batch programs or reports where they can query and manipulate the
secure business objects. This technique provides effective data level
security by removing access to a complete function in the applications.
This is fully supported in Oracle Applications and is achieved by careful
definition of menus and responsibilities.

If the standard application level features do not fully meet the

requirements, and the technique of removing access to particular
application functions cannot be used, it may be necessary to extend the
data-level security capability of the applications by customization. A
particularly effective technique is the use of secure views in separate
Oracle IDs to remove visibility of key business objects by putting a "tag"
on the data to indicate which business organization created the data and
should have access to it. This "tag" is usually populated by database
triggers and may be stored in a descriptive flexfield column on a
particular data entity (if possible) to prevent the need for additional table
columns on the base package tables.

It is important to understand what is meant by data access in this context

and in particular, the distinction between organization and user data
access. Data access restrictions arise from the fact that an organization
user creates a piece of data within a particular business operating
environment and only users in organizations that have an appropriate
business operating environment themselves, are able to read and
manipulate the data. The data is effectively imbued with access
properties from the business operating environment of the creator
organization. In order to manipulate a piece of data, a user may be
allowed to transform their business operating environment from that of
organization A into another environment that does allow access,
organization B. Organization A still does not have access to the data per
se—that privilege resides solely with the user.

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Application Security Mapping

The following table lists security requirements by application for each of
the implemented Oracle Applications derived from the security policies
and the Information Access Model.

The method that will be used to implement the security features are
briefly documented in the last column of the table.

Application Data Class Detail Function Standard Requirement Solution

Oracle

General Ledger Corporate GL Corporate Secure by Set Only Corporate users Standard
on-line/batch of Books should have Oracle
transactions and read/transaction access
reports
Revenue Entity GL Revenue entity on- Secure by Set Restrict read/transaction Standard
line/batch of Books access by other entities. Oracle
transactions and Corporate finance users
reports can read/transact any
data.
Payables Vouchers Read/transact Access to all Only match to POs for Access
access to Revenue Revenue Entity. through a
Entity Vouchers Corporate finance users secured
can read/transact any Oracle ID
data. using
views/synony
ms
On-line Invoice Access to form Only release holds for Access
Approvals Revenue Entity. through a
Corporate finance users secured
can read/transact any Oracle ID
data. using
views/synony
ms
Vouchers, Batch Posting of Access to Restrict access to Access
Credit/Debit journal entries Form vouchers, credit/debit through a
Memos memos by Revenue secured
Entity. Corporate Oracle ID
finance users can using
read/transact any data. views/synony
ms
Checks Batch Check Printing Access to all Restrict access to bank Access
accounts by Revenue through a
Entity. Corporate finance secured
users can read/transact Oracle ID
any data. using
views/synony
ms
Invoice Selection Paygroups & Restrict access by Access
Priorities Revenue Entity - through a
probably procedural secured
Corporate finance users Oracle ID
can read/transact any using
data. views/synony
ms
Assets Assets Run Depreciation Access to Restrict running by Legal Access
Form Entity for Legal Entity. through a
Corporate finance users secured
can read/transact any Oracle ID
data. using
views/synony
ms
Receivables Invoices AutoInvoice Access to all Restrict generation of Access
invoices by Revenue through a
Entity. Corporate secured
finance users can Oracle ID

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Application Data Class Detail Function Standard Requirement Solution

Oracle

read/transact any data. using

views/synony
ms
Credit Memos Apply Credit Memos Access to all Restrict invoice selection Access
by Revenue Entity . through a
Corporate finance users secured
can read/transact any Oracle ID
data. using
views/synony
ms
Cash Receipts Manual Receipts Access to all Restrict application to Access
Revenue Entity invoices. through a
Corporate finance users secured
can read/transact any Oracle ID
data. using
views/synony
ms
Invoices, Credit Posting Access to Restrict posting of Access
Memos Form invoices and so on by through a
Revenue Entity. secured
Corporate finance users Oracle ID
can read/transact any using
data views/synony
ms
Manufacturing Various Access to all Restrict transactions for Modification
Applications Mfg/Dist non-management to login form
Organizations employees to be entered of
against their Mfg/Dist Manufacturin
Organization only. All g Applications
Mfg/Dist users have read to restrict
only access to any data. login to
Mfg/Dist
Organization

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Application Security Design

This section describes the designs for functions or features that need to
be added to the applications and the overall systems environment to
meet the security requirements.

Oracle Applications are developed in adherence to strict design and

development standards. These standards insure high quality, portability
across multiple platforms, consistent look and feel, ease of maintenance,
and compatibility with future versions of Oracle Tools and Application
Object Library.

Customizations or extensions to Oracle Applications must also follow strict

standards for many of the same reasons, but must also take into
consideration factors such as ease of upgrades, preservation of core
functionality, maintainability, and the design review process.

Trusted Services

Trusted services involve the use of key encryption schemes, secure-token

authentication and other means of validating that the requester and
provider of a transaction are the intended parties. Further the transaction
may be encapsulated in an encryption scheme.

Payment Authorization Services

These services interact with bank and clearing organization servers to
secure pre-authorization for debts.

The project requirements for this type of service are:

·
·
·

Payment Transaction Services

These services interact with bank and clearing organization servers to
transmit actual payment and remittance information related to particular
transactions.

The project requirements for this type of service are:

·
·
·

Bill Presentation Services

These services interact directly business to business or business to
intermediary to business to present bills or invoices for subsequent
payment.

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999
The project requirements for this type of service are:

·
·
·

Business to Business Transmittals

These services interact directly business to business or business to
intermediary to business to transmit critical transactions such as
purchase orders, advance ship notices, receipt confirmations, and so on.

The project requirements for this type of service are:

·
·
·
·

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Application Security Configuration

The section describes in general terms how the application will support
the security requirements. The application configuration may use
standard application features that the application uses to provide the
supported security functions, or they may be custom extensions or
modifications to the applications that are needed to provide security at
the application level above and beyond what is provided in the standards
applications.

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Database Security Design

This section describes the design of a specific custom database
architecture to support the database level security requirements.

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Database Security Configuration

The section describes in general terms how the database will be
partitioned to support the general security requirements. The partitioning
may arise from a standard database level features that the application
uses to provide the supported security features, or they may be custom
modules that are needed to provide security at the database level above
and beyond what the applications support.

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only
TA.080 Application Security Architecture Doc Ref: <Document Reference Number>
June 14, 1999

Open and Closed Issues for this Deliverable

Open Issues

ID Issue Resolution Responsibility Target Date Impact

Date

Closed Issues

ID Issue Resolution Responsibility Target Date Impact

Date

<Subject> Open and Closed Issues for this Deliverable 10 of 10

File Ref: 877741615.doc (v. DRAFT 1A )
Company Confidential - For internal use only