Expose your Intranet Portal to the
Outside World in a Secured Manner
(aka. A Secured Inside/Outside Portal)
An Oracle White Paper
Expose your Intranet Portal to the Outside World in
a Secure Manner.
INTRODUCTION
With the introduction of web based technologies, the nature of
business and the way employees interact with an organization has
significantly changed. More and more users are accessing the
applications required to do their jobs via a telecommuting paradigm.
As such, the manner and number location from which employees use
these applications has also increased.
While ubiquitous access to corporate data and applications has
significant benefit for employees who are remote from the corporate
network, it does introduce some significant security concerns. The
granting of access rights to a given employee may be valid, based on
their role within the organization, however if there is no ability to
constrain how/where that user may accesses the information, how is it
possible to prevent the information being, either accidentally or
maliciously, exposed to an inappropriate audience. For example,
while it is reasonable that an employee access their personal HR data
within a secure environment, such as their office, viewing the same
information in a public forum, such as a cyber café, raises the
possibility of having the information read by those for whom it was not
intended. (Such as, simply being read over the user’s shoulder or, as is
unfortunately becoming more common, the use of a Trojan
screen/keyboard reader).
This can be as much of an issue for employees who are working in a
professional capacity within the secured network of a customer or
partner organization. Consultants for example, spend significant
portions of their working week out of the office at client offices. The
temptation to save time by accessing corporate applications (such as
timesheet reporting) is probably extremely high, yet exposes those very
applications to employees of the client organization.
In these scenarios, the use of a VPN is often not practical as it would
not be appropriate to install the client software locally on the machine
in question (especially in the case of the Cyber Café). The benefit of a
Virtual private Network is that is effective places the user on the
corporate network, and hence enables access to the same resources
which would be available to the user internally. Hence while useful for
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 2
a home office, may exacerbate the security issue. As such, for the
scenarios given, it is likely that the remote employees will use the
organizations external website (public) as the entry point to access their
Corporate Portal and associated web applications.
Cyber-Café
Home Office
VPN access
Remote Employees
(eg. Professional Services)
Public
Network
Corporate Network
Figure 1: Ubiquitous Access to the Web introduces the possibility of compromised data.
The issue for Portal administrators is therefore, how, given that access
permissions are based on an Access Control List (ACL) and the user’s
unique identity, is it possible to grant the user access to a page, yet limit
it to only to the secured intranet environment.
This whitepaper will introduce an extension to the OracleAS Portal 10g
(R2) security mechanisms, which allows for the definition of a nonsecured access path, and the subsequent ability to block secured
requests if they originate via that access path. The default extensions
shipped with OracleAS Portal 10g (R2) will cover the following three
requested security extensions.
•
Prevent the viewing of specific Portal pages, if the request
originated from outside of the Corporate Network.
•
Prevent the editing/customization of specific pages, if the user
requesting the page is outside of the Corporate Network.
•
Globally remove the ability for End Users to edit/customize
any accessible any page in the system, if the edit request
originated from outside of the Corporate Network.
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 3
INSIDE/OUTSIDE TOPOLOGY
The approach taken to secure ages from external access is an extension
to the standard OracleAS Portal 10g “Inside/OutSide” configuration as
described in the Oracle Application Server Configuration guide (see
Figure 2). In this configuration the two user communities are
separated through the use of two distinct middle tier installations, each
with it’s own Webcache and Application server. Both Middle-tiers
however are associated with the same Portal repository, allowing for
the same portal and access rights to be used across both the “internal”
and “external” sites.
Note: it is recommended that the two sites do not share the
same URL. This not only simplifies the network configuration
but also enforces different CacheKeys within the Webcache.
By the use of an “Invalidation-Only” cluster content is not shared
between the various cache nodes of the cluster, hence a request that
originated from with-in the secured network will only be cached on the
“Inside” while, conversely, a page request from the external network
will remain in the external cache. The separation of the application
servers to service two different communities further enhances the
security of the site by allowing the deployment of executable code to be
limited on the publicly accessible application server.
https://portal.outside.com
External Firewall
External Users
Reverse Proxy
'
External Application
Server
(Portal Middle-Tier)
On “Unsecured”
Network
Internal Firewall
http://portal.inside.com
“Invalidation-Only”
Cluster
External
Webcache
&
Internal Users
ORA_EXT_REQ
CGI variable
added to
request
Internal
Webcache
Internal Application
Server
(Portal Middle-Tier)
On “Secure” Network
8
Portal Metadata Repository
9
Check for ORA_EXT_REQ in Request
Figure 2: Extended "Inside/Outside" Topology
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 4
While the use of disparate mid-tiers allows for the separation of
content for the two logical communities it does not enforce which
community is which (simply that they are exposing independent
content). If an individual user may access the Portal from either site it
is necessary to physically differentiate the path used for the user’s page
request. In order to determine which community is “Outside” the
middle-tier servicing the page request is “flagged” as an external
service. Hence requests received via this server may be assumed to have
originated from the external “public” network.
The approach used to “flag” the external requests is via the addition of
a Common Gateway Interface (CGI) variable to the request as it
executes on the server that has be designated as “outside”. As the page
request is forwarded to the OracleAS Portal 10g repository for
verification of access privileges, the addition of the CGI variable
(ORA_EXT_REQ) to the request allows the security authorization
code to differentiate between the origins of a page request. That is, a
request from an internal server would not carry the ORA_EXT_REQ
variable.
In order to utilize the path information to further secure pages, an
Access Control List (ACL) modifier package is installed into the Portal
Repository to check for the existence of the CGI variable before
performing the standard permissions checks. This ACL modifier
package will be discussed later in this paper.
Note: The ORA_EXT_REQ variable has no specific value to
control the ability to access a page externally. The modifier
package simply checks for the existence of the variable, not the
value contained within it. As such, if the external server was
compromised and a malicious user was able to set this value, they
would succeed only in decreasing the amount of content available
to them.
Configuration Steps
The high level steps for configuring the prescribed “Inside/Outside”
topology are as follows;
1. Install the Product Metadata Repository on the internal Database
server (either in a custom database or using the Seed Meta-Data
Repository which is installed with the infrastructure install)
2. Install Portal & Wireless Mid-tier on the external mid-tier server,
associate this installation with the Metadata repository configured in
step 1, however DO NOT configure the portal during this
installation process (Note: uncheck to configure portal check-box)
3. Setup an Invalidation-only Web Cache Cluster between the two
mid-tiers configured above. (Refer to the Oracle® Application Server
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 5
Web Cache Administrator's Guide for steps on Configuring
“Administration and Invalidation-Only” Clusters)
4. Using the “Advance Server Properties” page from within the Oracle
Application Server Console edit the Oracle HTTP server and
mod_plsql configuration on the External mid-tier to flag this server
as unsecured (ie that which services the external requests)
Farm > Application Server Instance > HTTP_Server > Admininstration >
Advanced Server Properties
a) Edit the httpd.conf configuration file. Add a line as follows in
the main section:
SetEnv ORA_EXT_REQ
(this is the environment variable which denotes an externally
initiated request).
b) Edit the dads.conf mod_plsql configuration file, add a line
under the configuration entry for the Portal DAD as follows:
PlsqlCGIEnvironmentList ORA_EXT_REQ
c) Restart the HTTP Server:
5. Register both the Internal and external Portal URLs as separate
Partner Applications in the Oracle SSO environment
6. Setup Portal to Send Invalidation Requests to Internal Middle Tier
WebCache invalidation port.
Note: These steps are described in detail within the “Configuring a
Dedicated Intranet and Extranet for OracleAS Portal” chapter of the Oracle®
Application Server Enterprise Deployment Guide. Please refer to this
document for further information on how to configure the Enterprise
“Inside/Outside” topology.
Authorization Modification
In the basic installation of OracleAS Portal 10g, the determination of a
user’s ability to view or edit a page, is based on the definition of an
ACL policy, which references the page and the user (and/or any roles
to which they belong). In other words the user’s privileges are defined
by her as a “named” individual identity, rather than based on a specific
business rule (such as from whence the request originated).
To allow for extensions to this security model the OracleAS Portal 10g
authorization routines have been extended by the introduction of an
“Authorization Modifier Package”. This package is executed prior to
the standard ACL check, and enables additional rules to be evaluated
before interrogating the ACL itself. If the “Authorization Modifier”
succeeds (returns true) then the authorization check falls through to the
default ACL based mechanism in order to determine if the user has the
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 6
appropriate access rights. Conversely, if the “Authorization Modifier”
denies access (returns false) the ACL is not even interrogated, and the
behavior is to act as if the user did not have appropriate privileges for
the operation, even if the ACL would have allowed it.
By default, the installed “Authorization Modification Package” always
returns true, and hence the functionality is effectively disabled. Thus
the determination of access privileges is based solely on the evaluation
of the security ACL’s.
To ‘switch on’ the Authorization modifier it is necessary to replace the
default package body with one that implements the desired business
rule.
“Secure Network Aware” Authorization Modifiers
OracleAS Portal 10g is shipped with three predefined Modifier
packages which allow for the implementation of a “Secure Network
Aware” Portal environment. That is, one which is able to implement
security policies based not only on an ACL, but also on the origin of
the Portal page request.
Script File
Description
cfgamyes.pkb
The default ConFiGuration Authorization Modifier
disables ALL page Editing or Customization
functionality for requests which originate outside of
the secured network
cfgampev.pkb
The ConFiGuration Authorization Modifier for
Page Edit and View, allows for the securing of
individual pages outside of the Secured Network.
That is, the ability to prevent the viewing or editing
of specific pages when the request originated from
outside the secure network environment.
cfgamno.pkb
Returns the Authorization modifier to the default
disabled state.
Table 1: Authorization modifiers supplied
The Modifier packages may be found in the
$ORACLE_HOME/portal/admin/plsql/wwc directory of the
10.1.4 Metadata Repository Upgrade Assistant (MRUA)
To implement the desired function;
1. Connect via SQL*Plus to Database containing the OracleAS
Portal 10g Metadata Repository.
2. Login as the Portal schema
3. Execute the appropriate package body script file to over-write
the current Authorization Modifier installed.
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 7
Default Authorization Modifier
This implementation of the Authorization Modifier package uses the
existence of the ORA_EXT_REQ CGI environment variable
described above to recognize that the request has been received on a
server that has been designated as publicly accessible, and hence should
be considered outside of the “Secure Network” environment.
Once compiled into the Authorization packages, any request from
“outside” of the network which involves an Edit request is
automatically disabled. That is, all “customize” and “Edit” links are
removed from the page and direct edit URL references are disallowed.
The effect of the default modifier can be seen in Figure 3 below.
A Local Network request with Edit Privileges Allowed
http://ptlsrv-inside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL
An External Network request with all Edit Privileges Blocked
Ability to edit page is globally
blocked for ALL users.
Both Edit & Customize removed
from the page.
http://ptlsrv-outside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL
Figure 3: The effect of applying the Default Modifier on a user’s ability to
Edit/Customize the portal externally.
Page View and Edit Authorization Modifier
Securing Specific Pages
The more specific Authorization Modifier (cfgampev) also uses the
CGI variable to determine an external request. It however uses it in
conjunction with defined page meta-data, in the form of a custom page
attribute, to localize the desired inside/outside security to a subset of
pages within the portal.
Hence the ability to have externally available view and/or edit
privileges on a specific page is determined on whether one or both
named attributes are defined in the page in question.
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 8
Preventing External Viewing of a Specific Page
The ability to view a page externally is determined by the
'isViewRestricted'’ named custom attribute. Once defined as part of
the page description (through the use of a custom page template - see
below) the setting of this attribute will determine dynamically if the
page is to be viewable, or not. That is, when set to 'On' external
viewing of the page is prevented, while a value of 'Off' (the default)
indicates it is to be available externally. From the perspective of the
end user, the activation of this rule has the effect of removing any links
which reference the page as well as preventing any direct URLs to it
(such as via a browser bookmark). An example of the effect of the
“View Restricted” modifier may be seen in Figure 4.
A Local Network request to view a secured page
http://ptlsrv-inside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL
A “Network Secured Page” is NOT
exposed, if the request originates
from outside of the Local Network!
An External Network request by the same user
http://ptlsrv-outside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL
Figure 4: The effect of the "ViewRestricted" modifier is to remove evidence of the
secured page from external requests
Preventing External Edits and Customization for a Specific Page
In a similar manner, the use of another named attribute,
'isEditRestricted' will dictate whether a specific page may be edited
from outside of the “secured network”.
Note: This is different to the “Default Modifier” which globally
turns off the ability to perform any edit function on any page
within the Portal.
When the value of this attribute is set to ‘On’ the ability to
edit/customize the page is revoked, while setting it to 'Off' indicates
edits from “outside” are to be allowed. As can be seen from figure 5,
the effect of setting this attribute is to not only remove the page level
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 9
edit links, but also revoke the edit/customize capability of the Portlets
embedded within the page.
A Local Network request to view a secured page
http://ptlsrv-inside.au.oracle.com:7777/portal//page?_pageid=33,35142&_dad=portal&_schema=PORTAL
http://ptlsrv-outside.au.oracle.com:7777/portal//page?_pageid=33,35142&_dad=portal&_schema=PORTAL
An External Network request by the same user
The ability to edit a specific “Network
Secured Page” may be revoked if the
page request originated from outside
of the Local Network
Figure 5: The effect of the "EditRestricted" modifier is to remove the ability to
Edit/Customize the secured page externally
Defining Required Page Attributes for use with
Authorization Modifiers
While the attributes described above are not currently part of the
standard page meta-data, the extensible page model allows us to add
them in the form of “Custom Attributes” to our page definition. By
the creation of a custom page type to be used as the basis of the
“inside/outside” secureable pages it is a simple process to allow a page
designer to define declaratively whether the page is to be internally
secured or accessable both from with-in and with-out the secured
network. The following section documents the steps required to create
the appropriate page type used to secure a page via the “Authorization
Modifier” functions decribed above.
1.
From within the “Portal Navigator”, drill into the “Shared
Objects” node to define both the custom Attribute and Page types.
It is recommended that these be defined as “Shared Objects”
rather than scoped to a specific Page Group, as it allows for their
reuse across multiple Page Groups.
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 10
Figure 6 : Portal Navigator "Shared Objects" node
2.
Selecting the Attribute link, define a custom attribute with the
or
specific
name
of
either
“isViewRestricted”
“isEditRestricted” depending on the functionality desired. Take
special care to match the case structure of the name, as the
Authorization modifier rule is CASE sensitive.
Set the data-type of the attribute to BOOLEAN.
Note: In order to simplify the use of custom meta-data the
Oracle Portal 10.1.4 “Create Attribute” page no longer allows
for the separate definition of the attribute’s name. Instead
this is generated from the user supplied display name
(truncating any spaces). As such, it is easiest to create the
attribute with an initial display name matching the required
attribute name (in this case “isViewRestricted”) thus creating
an attribute of the same name.
Having created the initial attribute definition, edit the Display
name to reflect the function of the attribute. (See figure 7)
Figure 7 : Custom Attribute Definition
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 11
3.
Once the required custom attribute is defined it needs to be made
part of the meta-data of the page.
a. Create a “Custom Page Type” to define a “Network Securable
Page” based on the Standard Base Page type.
Note: As with the creation of the Custom Attribute Oracle
Portal 10.1.4 initially generates the Type name from the user
supplied display name (truncating any spaces). As the physical
type name is not used by the Authorization modifier, it should
be set to something that is meaningful, as it will be exposed in
the Page Design UI.
b. Edit the new Page Type and define the attributes associated
with it by selecting the Attributes tab.
c. Within the “Shuttle Picker” highlight the new custom attributes
and move them to the right hand side. Click the Apply button,
which will associate the attributes with the new page type and
expose their Properties in the Page Type Attributes tab.
d. Set the default value of the attribute to either “ON” or “OFF”
depending on your security requirements.
e. Check the “Required” Check Box in order for the Attribute
(and display name) to be exposed in the Page Type and
subsequently Page Designer user interfaces.
Figure 8: Define Custom Page type on which to build "Network Securable" pages
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 12
Figure 9: Associate the “network security” attributes with the custom Page Type.
4. Configure the Page Group to expose the new Page Type.
Note: Given the Network Securable page is based on the Standard
Base type you may wish to remove the standard type and expose
the new “secured” version in it’s place
Figure 10: Defining the Page Types to be available within page group
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 13
Defining a Network Secured page
Having defined the “Network Secured” page type and associated it
with the page group, it is a simple task for the Page Designer to select
the appropriate page type and check which network security rule are to
be enforced. That is, whether the page they are designing should be
constrained to the Local network, or be exposed to a less secure
environment.
Figure 11 : Page designers can now declaratively define if their page should be “Network Securable”
Restrictions on Authorization Modifiers
The techniques described in this white paper rely on the fact that the
page request in question would, under normal circumstances, be
defined by a security policy, and as such; access control would be
applied. Consequently there are a number of caveats that should be
taken into account for this functionality to perform as expected.
1. The Page in question must be a “Secured Page” and may
not be defined as a PUBLIC page.
Based on the fact that public pages are available to all users,
regardless of whether they have authenticated or not, they are
not scrutinized for access control, and hence the authorization
code, and subsequent modifier, is not called prior to displaying
the page.
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 14
Therefore it is a minimum requirement that “VIEW” privilege
be granted to the “AUTHENTICATED_USERS” group for
the page.
2. User cannot be defined as a “SITE Owner”.
Site Owners are assumed to have MANAGE privilege over any
page in the Site owned by them. As such, they effectively have
“super-user” privileges and there is no requirement to perform
an authorization check. In this case the authorization code is
again not called prior to displaying the page.
3. User should not have Global Edit Privileges
As with the user being defined as the “SITE Owner”, the
granting of the Global “EDIT ANY PAGE” privilege indicates
that the user in question should have the right to edit any page
in the system, regardless of the ACL’s defined. As such, the
page level authorization is ignored and the Authorization
Modifier not executed.
4. Page Security Should be defined at the “Page Level”
In many cases it is more convenient to define the access control
privilege at the Page Group Level and allow the individual page
to inherit the privilege. In the case of the Authorization
Modifier this would then restrict all pages in the Page group
rather than only those pages requiring the external restriction.
Conclusion
As the web makes ubiquitous access to corporate data possible and as
more employees take advantage of the flexibility of “tele-commuting”;
the onus is on systems administrators to secure their environment, such
that information is not inadvertently exposed to those for whom it was
not intended. Increasingly, it has become necessary to treat as possibly
hostile, any request that has not originated from within the physical
confines of the local network. As such, these external requests should
be limited to the minimum possible functionality.
This white paper has introduced the concept and techniques for
implementing a secured “Inside/Outside” topology for OracleAS
Portal 10g which allows a users access privileges to be determined not
only by their identity but also by the path used to access the Portal.
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 15
Appendix
Object level functions allowed by the default Authorization Modifier.
Object
Privilege
ADCALEND
EXECUTE
ADCHART
EXECUTE
ADFORM
EXECUTE
ADFORMPR
EXECUTE
ANY_APPLICATION
EXECUTE
ANY_ITEM
VIEW
ANY_LOG
VIEW
ANY_PAGE
VIEW
ANY_PORTLET
ACCESS
ANY_SCHEMA
VIEW
ANY_SITE
VIEW
ANY_STYLE
VIEW
APPLICATION
EXECUTE
AREPORT
EXECUTE
CHART
EXECUTE
DATACELL
DATAPTL
DOCUMENT
VIEW
EXECUTE
VIEW
DRIVER
EXECUTE
DYNAMIC
EXECUTE
FOP
EXECUTE
FOT
EXECUTE
HIERARCH
EXECUTE
IMGCHART
EXECUTE
ITEM
VIEW
LINK
EXECUTE
LOV
EXECUTE
MDF
EXECUTE
Allowed?
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 16
MDFORM
EXECUTE
MENU
EXECUTE
PAGE
VIEW
PORTLET
ACCESS
PORTLET_NON_LOCAL
ACCESS
QBEFORM
EXECUTE
REPORT
EXECUTE
RWCAL
EXECUTE
RWCPC
EXECUTE
RWPRN
EXECUTE
RWREP
EXECUTE
RWSVR
EXECUTE
SCHEMA
VIEW
SITE
VIEW
UIFORM
EXECUTE
URLPTL
EXECUTE
XMLPTL
EXECUTE
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
Expose your Intranet Portal to the Outside World in a Secured Manner - Page 17
Expose your Intranet Portal to the Outside World in a Secure Manner
Author: Barry Hiern
Contributing Authors: Paul Encarnación, Sunil Marya, Peter Lubbers
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
This document is provided for information purposes only and the contents hereof are subject to change
without notice.
This document is not warranted to be error-free, nor subject to any other warranties or conditions,
whether expressed orally or implied in law, including implied warranties and conditions of
merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to
this document and no contractual obligations are formed either directly or indirectly by this document.
This document may not be reproduced or transmitted in any form or by any means, electronic or
mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective owners.