Expose your Intranet Portal to the Outside World in a Secured Manner (aka. A Secured Inside/Outside Portal) An Oracle White Paper

Transcription

1 Expose your Intranet Portal to the Outside World in a Secured Manner (aka. A Secured Inside/Outside Portal) An Oracle White Paper

2 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 of locations 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 sites. 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

3 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 Public Network Remote Employees (eg. Professional Services) 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

4 INSIDE/OUTSIDE TOPOLOGY The approach taken to secure pages 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. External Firewall External Users Reverse Proxy External Application Server (Portal Middle-Tier) On Unsecured Network External Webcache Invalidation-Only Cluster Internal Firewall Internal Users ORA_EXT_REQ CGI variable added to request Internal Application Server (Portal Middle-Tier) On Secure Network Internal Webcache Portal Metadata Repository Figure 2: Extended "Inside/Outside" Topology Check for ORA_EXT_REQ in Request Expose your Intranet Portal to the Outside World in a Secured Manner - Page 4

5 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

6 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

7 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 cfgamyes.pkb cfgampev.pkb cfgamno.pkb Description The default ConFiGuration Authorization Modifier disables ALL page Editing or Customization functionality for requests which originate outside of the secured network 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. Returns the Authorization modifier to the default disabled state. Table 1: Authorization modifiers supplied The Modifier packages may be found in the $ORACLE_HOME/plsql/admin/wwc directory with the release of Oracle Application Server Portal. 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

8 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 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. 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

9 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 An External Network request by the same user A Network Secured Page is NOT exposed, if the request originates from outside of the Local Network! 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

10 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 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

11 Figure 6 : Portal Navigator "Shared Objects" node 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 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

12 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 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

13 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

14 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

15 Therefore it is a minimum requirement that 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

16 Appendix Object level functions allowed by the default Authorization Modifier. Object Privilege Allowed? ADCALEND ADCHART ADFORM ADFORMPR ANY_APPLICATION ANY_ITEM ANY_LOG ANY_PAGE ANY_PORTLET ANY_SCHEMA ANY_SITE ANY_STYLE APPLICATION AREPORT CHART DATACELL DATAPTL DOCUMENT DRIVER DYNAMIC FOP FOT HIERARCH IMGCHART ITEM LINK LOV MDF ACCESS Expose your Intranet Portal to the Outside World in a Secured Manner - Page 16

17 MDFORM MENU PAGE PORTLET PORTLET_NON_LOCAL QBEFORM REPORT RWCAL RWCPC RWPRN RWREP RWSVR SCHEMA SITE UIFORM URLPTL XMLPTL ACCESS ACCESS Expose your Intranet Portal to the Outside World in a Secured Manner - Page 17

18 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 U.S.A. Worldwide Inquiries: Phone: Fax: Copyright 2005, Oracle. All rights reserved. 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.