secured inside outside - oracle.com · dedicated intranet and extranet for oracleas portal”...

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 Secured Manner -

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


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.

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 non-secured 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.

Cyber-Café

Home OfficeVPN access Remote Employees

(eg. Professional Services)

Corporate Network

PublicNetwork

Figure 1: Ubiquitous Access to the Web introduces the possibility of compromised data.


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.

http://portal.inside.com

Reverse Proxy

External Firewall

“Invalidation-Only”Cluster

Internal Firewall

Internal Webcache

External Webcache

External Application Server (Portal Middle-Tier)On “Unsecured”Network

ORA_EXT_REQ

Check for ORA_EXT_REQ in Request

CGI variable added to request

Portal Metadata Repository

Internal Application Server (Portal Middle-Tier)On “Secure” Network

Internal Users

External Users

https://portal.outside.com

Figure 2: Extended "Inside/Outside" Topology


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


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


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.


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.

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.

http://ptlsrv-inside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL

Ability to edit page is globally blocked for ALL users. Both Edit & Customize removed from the page.

A Local Network request with Edit Privileges Allowed

An External Network request with all Edit Privileges Blocked

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.


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.

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

A “Network Secured Page” is NOTexposed, if the request originates from outside of the Local Network!

http://ptlsrv-outside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL

http://ptlsrv-inside.au.oracle.com:7777/portal/page?_pageid=33,35139&_dad=portal&_schema=PORTAL

A Local Network request to view a secured page

An External Network request by the same user

Figure 4: The effect of the "ViewRestricted" modifier is to remove evidence of the secured page from external requests


edit links, but also revoke the edit/customize capability of the Portlets embedded within the page.

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.

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


2. Selecting the Attribute link, define a custom attribute with the specific name of either “isViewRestricted” or “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 6 : Portal Navigator "Shared Objects" node

Figure 7 : Custom Attribute Definition


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


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 9: Associate the “network security” attributes with the custom Page Type.

Figure 10: Defining the Page Types to be available within page group


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.

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.

Figure 11 : Page designers can now declaratively define if their page should be “Network Securable”


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.


Appendix Object level functions allowed by the default Authorization Modifier.

Object Privilege Allowed? 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 VIEW

DATAPTL EXECUTE

DOCUMENT VIEW

DRIVER EXECUTE

DYNAMIC EXECUTE

FOP EXECUTE

FOT EXECUTE

HIERARCH EXECUTE

IMGCHART EXECUTE

ITEM VIEW

LINK EXECUTE

LOV EXECUTE

MDF EXECUTE


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

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.

secured inside outside - oracle.com · dedicated intranet and extranet for oracleas portal”...

Documents