Implementing Oracle Internet Directory Security PDK-Java provides a set of

7-46 Oracle Fusion Middleware Developers Guide for Oracle Portal ■ Secures data within your portlets based on the users group membership. ■ Creates users and groups directly from your portlets exposed as Web providers. The disadvantages of Oracle Internet Directory security are as follows: ■ Slightly degrades performance when authorizing your portlet through Oracle Internet Directory. There is a cost associated with obtaining group information from any LDAP server, but this cost only happens the first time a user accesses a portlet in a session. ■ Requires provider access to Oracle Internet Directory. ■ Assumes all Oracle Portal instances served by the provider use the same Oracle Internet Directory instance. For more information on securing your providers using Oracle Internet Directory or to set up the sample portlets secured using Oracle Internet Directory, review the technical note, Installing the Oracle Internet Directory Portlets on OTN.

7.2.7.9.2 Viewing Your Portlets After you secure your provider with Oracle Internet

Directory, you can validate its behavior by following these steps:

1. Ensure you are logged in to an Oracle Portal instance as a user who is a member of

the group specified in the group tag in provider.xml.

2. Use an existing page or create a new one, ensuring it is visible to PUBLIC.

3. Add your Java portlet to the page.

4. Make a note of the direct URL to your new page.

5. Click Logout.

6. Directly access the page by entering the URL noted in Step 4 in your browsers

address bar or login to Oracle Portal using a user that is not part of the group listed in provider.xml. You will see the page created in Step 2 but not the portlet added in Step 3, as shown in Figure 7–10 . When you added the portlet to the page, you were logged in as a user authorized to view the portlet. The PDK runtime detected this and allowed you to add the portlet. When you logged out and viewed the page, you were no longer part of the group allowed to view the portlet and hence the PDK Framework did not allow rendering of the portlets contents. Figure 7–10 Page and Portlets for Developer If you log in again and view the page, you will see that the portlet is still there Figure 7–11 . Enhancing Java Portlets 7-47 Figure 7–11 Page and Portlets for DeveloperAdministrator

7.2.7.10 User Input Escape

By accepting user input without escaping it to text, you run the risk of an XSS attack, where an attacker attempts to pass in malicious scripts through user input forms. For example, if a portlet title is customizable, an attacker might attempt to pass scripts or commands to the portlet through the title string. Oracle Portal provides the following features to ensure that you can protect your portlets from such attacks: ■ Section 7.2.7.10.1, Default Container Encoding ■ Section 7.2.7.10.2, Escape Methods

7.2.7.10.1 Default Container Encoding To prevent any script inside a portlet title from

being executed, the framework default container renderer class encodes any script characters. This default behavior is controlled through a JNDI variable, escapeStrings. When set to true, the markup tags in portlet titles are rendered as visible tag characters. For example, a title customization of ititlei will be rendered as ititlei not title. This mode is secure, but, if it is not the desired behavior, you can set escapeStrings to false for that provider. escapeStrings applies to all logical providers within a Web provider. You can set the value of escapeStrings from the WebLogic Server Administration Console as you would any other JNDI variable. Refer to Section 7.2.4.2, Setting JNDI Variable Values for more information.

7.2.7.10.2 Escape Methods If you have code that renders customized values, you need

to ensure that you escape those input values appropriately to avoid XSS attacks. This requirement applies to code for rendering pages in any mode. Oracle Portal supplies two new static methods for this purpose. They are in the Java class oracle.portal.provider.v2.url.UrlUtils, and can be described as follows: ■ public static escapeStringstring_text escapes any script characters in a given string. For example, less than becomes lt. This method is unaffected by the escapeStrings JNDI variable and is the secure, recommended method to use. ■ public static escapeStringByFlagstring_text escapes any script characters in a given string. This method is controlled by the escapeStrings 7-48 Oracle Fusion Middleware Developers Guide for Oracle Portal JNDI variable and is therefore less secure and not the recommended method to use. For example: title = UrlUtils.escapeStringdata.getPortletTitle;

7.2.8 Controlling the ExportImport of Portlet Personalizations

The exportimport facility of Oracle Portal is a multi-purpose tool for moving your portal objects, such as portlets, between instances of Oracle Portal. For example, you might use exportimport to move objects from a development environment to a stage environment and then, finally, to a production environment. You might also use exportimport to move pages and page groups between Oracle Portal instances, or to move Web providers from one machine to another. For more information about exportimport in general, please refer to the Oracle Fusion Middleware Administrators Guide for Oracle Portal. Because portlet default settings can be set by the administrator and then changed by the user, they require some special consideration when you import and export them. To simplify the transport process, Oracle Portal provides default functionality that handles administrator personalization data that is, data created using Edit Defaults mode for you. When a portlet is exported, the default personalization data stored using PDK-Javas PreferenceStore mechanism is exported with the portlet by default. Hence, when the portlet is imported into a target instance of Oracle Portal, this data is imported along with it. As a result, the portlet instances default settings are maintained when the portlet is moved from one portal instance to another. 1 The aforementioned behavior is provided to you as a convenience and it requires no action on your part to leverage. You might, however, want to exercise more granular control over the export of personalization data than that provided by the default functionality. To implement your own requirements for exportimport, you can make use of the programming interface to augment or override the default handling of personalizations. If you use the PDK-Java preference store mechanism, the exportimport of your Edit Default personalizations is built-in and requires no additional effort on your part. This default exportimport of administrator personalizations relies on the PDK-Java preference store. If you have created your own preference store mechanism for example, a file or database preference storage system, then you also must implement your own exportimport support that performs the following functions: ■ Exports personalizations. This functionality must at least export administrator personalizations, but it could optionally include user personalizations, too. ■ Imports personalizations. Note that this functionality must reflect whatever you implemented for export. For example, if you allow the export of both administrator and user personalizations, then the import functionality must support both as well. The exportimport functionality for personalizations requires that your Oracle Portal instance and provider are on Release 10.1.2. Exportimport of personalizations behaves the same regardless of the location of your provider, which can be either of the following: ■ in the default Oracle Containers for Java EE of the Oracle Application Server, where the Oracle Portal instance is different. 1 User personalization data for Oracle Portal objects is never exported. This restriction applies to portlets as well as other objects, such as pages.