DMZ (DeMilitarized Zone)
Company requirement
Large Organizations want to expose their Oracle Application services outside their
private network (HTTP/HTTPS and SSL). Usually these exposures must exist to promote
external communication. So they want to separate an external network from directly
referencing an internal network
Company issue
Business does not want to compromise with security information
Business cannot expose internal domain or internal URL information
Company requirement
DMZ is the solution of this problem. In Oracle application we can achieve this by following way –
Oracle Application consists of fleet nodes (FND_NODES) so first decide which node have to
expose to public
To expose the node to public use the profile “Node Trust Level”
Set node to Public/Private (Normal -> private, External -> public)
Set "Responsibility Trust Level" profile to decide whether to expose Application Responsibility
to inside or outside firewall.
Oracle E-Business Suite R12 Configuration in a DMZ (Doc ID 380490.1)
The DMZ, which stands for DeMilitarized Zone consists of the portions of a corporate network that are between the corporate intranet and the Internet. The DMZ can be a simple one segment LAN or it can be broken down into multiple regions. The main benefit of a properly-configured DMZ is better security: in the event of a security breach, only the area contained within the DMZ is exposed to potential damage, while the corporate intranet remains somewhat protected.
DMZ is the way of exposing organization specific files to outside firewall.In Oracle Aplications we can achieve this.Oracle Application architecture consists of fleet of nodes ( FND_NODES). First we need to decide which nodes we need to expose to public.Using the profile "Node Trust Level" we can set a node to public or private ( Normal -> private,External -> public ).
Following table shows the entries of FND_NODES table.
FND_NODES
|
SVD0ORACS03
|
SVD0OAPS01
|
AUTHENTICATION
|
SVD0OAPS02
|
SVD0OAPS03
|
SVD0OAPS04
|
SVD0SSWEBS1
|
SVD0SSWEBS2
|
SVD0ORACS01
|
SVD0ORACS02
|
Following is the picture of "Node Trust Level" profile.
Node
|
Node Trust Level
|
SVD0ORACS03
|
Normal
|
SVD0OAPS01
|
Normal
|
AUTHENTICATION
|
Normal
|
SVD0OAPS02
|
Normal
|
SVD0OAPS03
|
Normal
|
SVD0OAPS04
|
Normal
|
SVD0SSWEBS1
|
External
|
SVD0SSWEBS2
|
External
|
SVD0ORACS01
|
Normal
|
SVD0ORACS02
|
Normal
|
In the above listed nodes two nodes are identified as External (SVD0SSWEBS1 and SVD0SSWEBS2). Rest others are Internal.
Following picture shows the profile setting of "Node Trust Level" for SVD0SSWEBS2.
In Responsibilities level also we can decide weather to expose it to inside or outside firewall.This can be achieved by using another profile "Responsibility Trust Level".
I will explain this profile with an example.I will create a responsibility and i will set the "Responsibility Trust Level" toExternal.So when user invokes the application from outside then he/she can view the responsibility.
1) Create a form function which points to an OAF page as shown below.
2) Assign the above function to a responsibility.
3) Set the "Responsibility Trust Level" of above created responsibility to "External".
4) Set the "Responsibility Trust Level" of Employee Self-Service responsibility to "External".
5) "Responsibility Trust Level" of Web ADI responsibility is "Normal".
Note: Run auto-config to complete the configuration.
When user tries to access application from inside firewall following responsibilities will display under his/her user.
1) Employee Self Service
2) Login Info
4) Oracle Web ADI
1) Employee Self Service
2) Login Info
4) Oracle Web ADI
When he/she tries to access application from outside firewall following responsibilities will list.
1) Employee Self Service
2) Login Info
1) Employee Self Service
2) Login Info
Large Organizations want to expose their Oracle Application services outside their
private network (HTTP/HTTPS and SSL). Usually these exposures must exist to promote
external communication. So they want to separate an external network from directly
referencing an internal network
Company issue
Business does not want to compromise with security information
Business cannot expose internal domain or internal URL information
Company requirement
DMZ is the solution of this problem. In Oracle application we can achieve this by following way –
Oracle Application consists of fleet nodes (FND_NODES) so first decide which node have to
expose to public
To expose the node to public use the profile “Node Trust Level”
Set node to Public/Private (Normal -> private, External -> public)
Set "Responsibility Trust Level" profile to decide whether to expose Application Responsibility
to inside or outside firewall.
Solution
Exposed web services can be accessed by both internal and external users
Configurable and can be very easily rolled out
Internal network and business data is secured from outside traffic
Unauthorized access to internal network from outside is prohibited
No need for VPN and Secure FTP server
Advantage
Large Organizations having Oracle Application can expose their web services like
(HTTP/HTTPS and SSL) to the internet without compromise with security information
and without exposing their internal domain
Disadvantage
If external firewall is compromised, then external application server is also compromised,
exposing an attack on E-Business Suite database
There’s nothing to prevent internal users from attacking internal application server,
also exposing an attack on E-Business Suite database
Oracle E-Business Suite R12 Configuration in a DMZ (Doc ID 380490.1)
