Sie sind auf Seite 1von 15

ORACLE RED PAPER

Oracle e-Business Suite


Security Explained

Author: Tim Wells


Tim.Wells@oracle.com
Creation Date: 15th March 2001
Last Updated: 20th April 2001
Document Ref: e-Business Suite Security Red Paper
Version: 2b
Document Control

Change Record15
Date Author Version Change Reference

15/03/2001 Tim Wells 1a No Previous Document


15/03/2001 Tim Wells 1b Significantly enhanced
02/04/2001 Tim Wells 1c Significantly enhanced
03/04/2001 Tim Wells 1d First Release
06/04/2001 Tim Wells 2a Clarification of details from customer feedback. Addition
of a example security architecture.

Reviewers
Name Position
Senior
Tim Wells Senior Principal Sales Consultant
Contents

1. Introduction..............................................................................................
1.1 Purpose..................................................................................................
1.2 Terminology...........................................................................................

2. Enterprise Wide User Security .............................................................5


2.1 Overview..................................................................................................
2.2 Single Sign-on...........................................................................................
2.3 PKI/ Digital Certificates.......................................................................

3. End-To-End Data Security .................................................................11


3.1 SSL Support...........................................................................................
3.2 Data Encryption/Obfuscation.................................................................

4. Central Security Management ......................................................12


4.1 Monitoring................................................................................................
4.2 Control......................................................................................................
4.3 System Administration.........................................................................

Appendix A - Bibliography ………………………………………… 15

Appendix B - Example e-Business Suite Security Architecture …. 15


1. Introduction

1.1 Purpose
As business’s migrate to an e-business model, organisations are opening up their IT systems
to their employees, partners, suppliers and customers. Therefore a strong security policy is
essential to ensure data confidentiality is maintained.

The purpose of this document is to explain the strong security features embedded in the
Oracle e-Business Suite. The Oracle e-Business Suite builds upon the operating system
security to provide a strong, flexible security mechanism, with a pre-defined configuration
for rapid implementation.

1.2 Terminology

Term Meaning
LDAP Light Directory Access Protocol. A class of directory.
Analogous to a phone book.

Single Sign-on Authenticate a user once for access to multiple applications.


DMZ De-Militarised Zone
Authentication Identification of the individual
Authorisation Permission to access a menu, screen, report or data set.
Digital Certificates A certificate which identifies a person or organisation.
PKI Public Key Infrastructure
Non-Repudiation A facility to prove without dispute that a transaction was
performed by a specific user.
2 Enterprise Wide User Security

2.1 Overview
Figure 1 depicts the user security features provided by the e-Business Suite to protect against
unauthorised users accessing the system, and limiting the scope of each authenticated user’s
access.

User Authentication
Username & Digital eye Enterprise
Fingerprints
Password Certificates scan Wide
Directory

User Authorisation
Responsibilities (roles) Users
Id
Name
Finance Finance Customer Telesales Password
Clerk Director Services Mgr Agent
Phone#
Pager#
Digital Certificate

System Privilages
Responsibilities
Finance Finance Customer Telesales
Menu Reports Services Stats Agent Screen

02/04/2001 1

Figure 1. User Security Architecture

Each user, whether internal or external to the organisation, must be authenticated before
gaining access to the Oracle e-Business Suite. As default this is achieved via a username and
password. However other mechanisms of authentication such as fingerprints and eye scans
can be used where appropriate. Authentication details provided by the user are compared
with the details stored in the Directory. This can either be the Oracle LDAP Internet
Directory (part of the Oracle Internet Platform), or the internal directory held in database
tables (FND_USER) on the data server. Other directories such as Microsoft Active Directory
and iPlanet can be synchronised with the Oracle Internet Directory to provide an Enterprise
wide directory.

A flexible password mechanism is provided to insure best practice password management


policies can be implemented. E.g. password ageing, automatic password expiry, see section
4.2 for further details.

Once authenticated, a user’s level of authorisation to the Oracle e-Business Suite is limited
via Responsibilities. Each user is allocated at least one Responsibility, one of which is active
at any one time. A user’s active Responsibility determines the scope of their access to the
Oracle e-Business Suite.
A Responsibility (or role) consists of a set of system privileges which typically enable a user
to be performed a business role within the system e.g. Finance Clerk, Customer Service
Manager. The type of system privileges that can be granted to a Responsibility by the
System Administrator are :

· Menus - grants the Responsibility access to a specific menu function.


· Screens, Report and Programs - grants the responsibility access to run a specific screen,
reports or programs.
· Data - grants the Responsibility access to a table or view of data. Access can be limited to
a subset of records and/or columns via views or via the data server’s fine grain data
security feature.

Creating generic Responsibilities and assigning them to users enables user administration
costs to be kept to a minimum.

Users maintain their own password and have the ability to alter their own security
preferences. Users can define notification rules that allow them to delegate, or automatically
respond to any one or more types of workflow notifications. A user can delegate a
notification, granting someone else permission to act on their behalf while still maintaining
ownership of the notification. Or, transferring complete ownership and responsibility for the
notification to another user.
2.2 Single Sign-on

The Oracle e-Business Suite provides a single sign-on capability using the Oracle Login
Server (part of the Oracle Internet Platform). Login Server provides a single sign-on
capability for two classes of application : partner applications, and external applications. The
e-Business Suite is a partner application.

Partner applications are those that have been designed or modified to work within the single
sign-on framework provided by Login Server. They delegate responsibility for user
authentication to the Login Server.

External applications are those which have not been modified to work within the single sign-
on framework, and retain responsibility for authenticating their own username and
passwords.

The sections below describe the process of authenticating both partner and external
applications.
Initial Login

A1 URL
Access
e-Business Suite Application
Request 1 9
Application A1 A1 Data
8

A1 Cookie

2 7
Encrypted
Token A1 Directory

3 Users
Login Id
Name
Page
4 Login Server 5 Password
Phone#
Pager#
Digital Certificate
SSO Cookie 6

02/04/2001 1

Figure 2a. Single Sign-on Architecture - Initial Login

1. User makes a URL Request via HTTP(S) to access Application A1.


2. Application A1 determines the user isn’t authenticated (no Application A1 cookie in the
user’s browser). Application A1 therefore redirects the user to the Login Server to obtain a
token of authentication for Application A1.
3. Because no SSO cookie is present in the user’s browser, the Login Server challenges the
user with the username and password login page.
4. Client responds with a username and password.
5. The Login Server verifies the username and password provided against the details in the
Directory.
6. If the details provided match the directory entry, the Login Server sets the SSO cookie in
the user’s browser to signify identify the user and that the user has been authenticated
with the Login Server. An expiration date and time is set on the SSO cookie according to
parameters settings.
7. Login Server redirects the user back to Application A1 with an encrypted token
authenticating the user to Application A1.
8. Application A1 sets the Application A1 cookie in the user’s browser.
9. Application A1 allows access to the screens and data of Application A1 according to its
authorisation settings.
Subsequent Login: To Partner Application

A2 URL
Access
e-Business Suite Application
Request 1 6
Application A2 A2 Data
5
A2 Cookie

2 4
A1 Cookie
Encrypted
SSO Cookie Directory
Token A2

SSO Cookie
Users
Id
Name
Login Server 3 Password
Phone#
Pager#
Digital Certificate

02/04/2001 1

Figure 2b. Single Sign-on Architecture - Partner Application Login

1. User makes a URL Request via HTTP(S) to access Application A2.


2. Application A1 determines the user isn’t authenticated (no Application A1 cookie in the
user’s browser). Application A1 therefore redirects the user to the Login Server to
obtain a token of authentication for Application A2.
3. Login Server uses the SSO cookie in the user’s browser to identify the user (avoiding the
need to challenge the user again with a login page) and accesses the Directory to
verify whether or not the user is allowed access to Application A2.
4. If access is allowed, the Login Server redirects the user back to Application A2 with an
encrypted token authenticating the user to Application A2.
5. Application A2 sets the Application A2 cookie in the user’s browser.
6. Application A2 allows access to the screens and data of Application A2 according to its
authorisation settings.
Subsequent Login: To External Application

B1 URL
Access
Application
Request 1
e-Business Suite 5

Application B1 B1 Data
A2 Cookie

2 4
A1 Cookie
Encrypted
B1 Username Directory
& Password
SSO Cookie
Users
Id
Name
Login Server 3 Password
Phone#
Pager#
Digital Certificate

02/04/2001 1

Figure 2c. Single Sign-on Architecture - External Login

1. User makes a URL Request via HTTP(S) to access Application B1.


2. Application A1 determines the user isn’t authenticated (no Application A1 cookie in the
user’s browser). Application A1 therefore redirects the user to the Login Server to
obtain a Username and Password for Application B1.
3. Login Server uses the SSO cookie in the user’s browser access the Directory to access the
username and password for Application B1.
4. If access is allowed, the Login Server redirects the user back to Application B1 with a
Username and Password for Application B1.
5. Application B1 allows access to the screens and data of Application B1 according to its
authorisation settings.

Logout

1. Login Server resets the SSO cookie in the user’s browser and marks it as expired.

2.3 PKI/ Digital Certificates


There are plans provide PKI authentication to the Oracle e-Business Suite in a future 11i
release. This will be achieved by PKI-enabling the Login Server. X.509 Digital certificates
will then be able to be used, as well as username and passwords, to authenticate the user with
the Oracle e-Business Suite and other partner applications. PKI enablement will also enable
non-repudiation of transactions.

Meanwhile PKI requirements can be satisfied by a complete, out of the box PKI solution that
incorporates our partnership between Entrust Corp. and Oracle. It utilises the Oracle Internet
Directory. For further information see the following information:
· http://www.oracle.com/tellmemore/?135501 and the press release
· http://www.oracle.com/cgi-bin/press/printpr.cgi?
file=200002070500.23232.html&mode=corp
· http://www.entrust.com
3. End To End Data Security

The Oracle e-Business Suite provides end-to-end data security, protecting data from access or
modification whilst in transit between the database and the desktop screen.

&(@%zQ* &(@%zQ*

HTTPS Sqlnet(SSL)
£1000 e-Business Suite
:&5%w*z
Application
^^}**px%z ^^}**px%z

HTTPS Sqlnet(SSL)

02/04/2001 1

Figure 3 end-to-end data security.

3.1 SSL Support


The Oracle e-Business Suite supports Secure Sockets Layer (SSL) to ensure data is not
changed or accessed during transmission. SSL version 3, 128 and 40 bit are supported for all
transmissions. Users accessing the system via the Internet will have an HTTPS connection to
the applications server in the DMZ. The applications server in the DMZ can have a
SQLNET/SSL connection to the infrastructure behind the firewall.

The Oracle e-Business Suite is agnostic to whether the encryption/decryption is performed in


software or hardware.

3.2 Data Encryption/Obfuscation


The Oracle e-Business Suite provides data encryption to ensure confidentiality of
information during storage. Passwords are stored in encrypted form in Oracle database
tables. The Oracle database encrypts all passwords using a one-way encryption algorithm,
based on a implementation of DES. Some of the information required to decrypt the
password is discarded during encryption, thus the encrypted password contains insufficient
information to decrypt the password, even if the user knows the encrypted password and the
algorithm. Thus the password mechanism does not depend on secrecy of the algorithm to be
effective.

There are plans to encrypt other sensitive applications data in a future release of the Oracle
e-Business Suite. This will be achieved by exploiting the encryption facilities in Oracle9i.

Meanwhile applications data encryption requirements can be satisfied via the Oracle 11I
encryption toolkit or via the Oracle partnership with Protegrity. Further information about
Protegrity can be found at http://www.protegrity.com/product.html.
4. Central Security Management

The Oracle e-Business Suite provides a comprehensive range of monitoring, control and
administration tools to centrally manage a business’s security policy. Thereby reducing
complexity, and minimising the cost of ownership.

4.1 Monitoring

The Oracle e-Business Suite provides a range of facilities for monitoring the usage of the
system.

AUDITING

User Auditing

The Oracle e-Business Suite audits user activity. The system allows each user access to be
recorded. The username, terminal id, the date and times of the user access is recorded, as
well as the Responsibility selected, screens and reports used and the concurrent processes
executed. The auditing facility allows the administrator to select the level of auditing
required. This may be dynamically changed at any time..

The Oracle e-Business Suite can monitor unauthorised user access. An audit log
( fnd_unsuccessful_logins table) is maintained of invalid authorisation attempts. The user
name, user id, terminal id, and data and time of the attempted login are logged.

Data Auditing

The Oracle e-Business Suite audits access to data. The system allows the auditing of data
insertion, updating and deletion to any column, in any table within the system. All data and
transactions within the Oracle e-Business Suite record the :
· creation date
· who created the record
· when it was last updated
· who updated the record

The auditing facility allows the System Administrator to dynamically set the level of auditing
per data table.

Security Reports

A range of security reports are provided with the system to produce formatted information
from the audit data. Example report include :
· Sign on Audit Concurrent Requests Report – audit of report request/access
· Sign on Audit Forms Report – audit of screens access
· Sign on Audit Responsibilities Report – audit of responsibilities usage
· Sign on Unsuccessful Logins Report – unsuccessful login activity
· Sign on Audit Users Report – audit of user access

These reports are available printed and online.

Alerts

Alerts can be configured to fire when entries are added to an audit log. This facility can be
used to alert a System Administrator when a potential security breach occurs, and/or execute
actions to protect the system from further access.

Non Repudiation
The Oracle e-Business Suite will facilitate the use of digital signatures to authenticate a
transactions. This provides a means of auditing transactions so they cannot later be disputed
to have occurred.

4.2 Control
A System Administrator can change a user's system privileges be modified dynamically. E.g.
changing a users’s approval limits will take effect the next time the user performs that
function i.e. Receives a requisition for approval via Workflow. Changing a user’s privileges
to menus, screens and reports will take effect the next time the user logs into the application
or changes Responsibility

Account Management

The Oracle e-Business Suite provides a range of features to allow best practice account
password management policies to be implemented. Users maintain their own passwords,
however they must conform to a set of rules which are set by the System Administrator.
These rules can be set at the system or user levels. Password rules include:

· A users password expires after a specified age.


· A users password expires at a specified data and time.
· A users password expires after logging in N times.
· A user may not reuse the previous password.
· A users password must have a minimum length (default is 5 characters).
· A users account will be disabled after N failed login attempts.

Only a system administrator has the authority to (re)establish an account by (re)setting the
user’s password. Passwords are not visible to users or System Administrators at any time.
Passwords are stored in encrypted form, and password characters typed in by users during
authentication are replaced with the "*" character.

A System Administrator may disable a user account at any time. Disabling the user will no
longer allow the user to login or to perform any approvals. If the user is already logged in, or
is approving requisitions via email, setting that users approval limit to zero, will
immediately prevent workflow from approving any requisitions or responses received from
them.

The Oracle e-Business Suite can automatically disable a user account after a configurable
number of failed login attempts. This facility can be implemented using the Alert feature
described above.

Session Management

The System Administrator can set a parameter to terminate inactive sessions after a specific
period of time.

The System Administrator can also set a parameter to activate sign-on notification. Sign-on
notification shows the user any concurrent requests failed since the last session, and how
many times someone tried to log on to Oracle e-Business Suite with your username but an
incorrect password.

4.3 System Administration


·
System Administration is a responsibility (role) in the Oracle e-Business Suite. Therefore
multiple users can be assigned the role, or subsets of the role. E.g. An administrator may
have authority for a single organisation or multiple organisations. By default, System
Administrators have authority for multiple organisations.

The Oracle e-Business Suite is shipped with several default administrative Responsibilities
to decrease the cost of implementing a business’s security policy. These defaults can be
extended and reconfigured to implement the selected security policy.

· OEM & application Management pack


·
· LDAP Directory
·
· The Oracle e-Business Suite can be configured to use the OID as the single point of user
security information.
·
· Enter & Maintain data
· Admin Screens
· Bulk Loading
· Replication with other Directories

· PlanXOS-security (HPUX/NT)
· XDB-security (Oracle)XLDAP v3
· (e.g. Active Directory)XPKIOther
·
· Migrating from NT Domain to PKI & an Enterprise Directory.
Appendix A - Example e-Business Suite Security Architecture

Below is an example security architecture to provide external access to the e-Business Suite
from outside and inside the organisation.

External
Web Server Internal
eg. 192.168.1.1 e-Business
Suite
Access

Encrypted Encrypted Application


Data Data Server
eg. 171.10.1.22

Internet DMZ Intranet


External External External DMZ DMZ
e-Business Router Firewall Firewal Router Data Server
Suite
Access

Data

20/04/2001 1

Appendix B - Bibliography

More information pertaining to Oracle Internet Directory may be found at:

· http://technet.oracle.com/docs/products/oid/doc_index.htm
· http://technet.oracle.com/products/oid/
· http://www.oracle.com/database/oid/

Das könnte Ihnen auch gefallen