Implementing Session Storage You built a portlet using the wizard and successfully added it to a page.

Enhancing Java Portlets 7-35 your provider or portlets. By setting this flag to true, extra load is added to the provider calls. provider class=oracle.portal.provider.v2.DefaultProviderDefinition sessiontruesession For more information on the syntax of provider.xml, refer to the provider Javadoc on OTN: http:www.oracle.comtechnologyproductsiasportalhtmljavadocx ml_tag_reference_v2.html

4. Register the provider in Oracle Portal. Ensure that you select the User radio button

and choose a Login Frequency of Once Per Session on the Define Connections page of the wizard. For a reminder on how to register your portlet, refer to Section 6.5.5, Registering and Viewing Your Oracle PDK-Java Portlet .

7.2.6.3 Viewing the Portlet

If you have not already added your Java portlet to a page, do so now. Ensure that you perform the following tasks: ■ Set your provider to Once per User Session for the login frequency value. ■ Refresh the provider to accept the new changes. ■ Re-login in case your session is no longer valid.

7.2.7 Implementing Portlet Security

This section describes the available security services for your Java portlet. For more detailed information about the PDK classes referred to in this section, refer to the Javadoc on OTN by clicking Java Doc API on the Portlet Development page available at http:www.oracle.comtechnologyproductsiasportalportlet_development_ 10g1014.html

7.2.7.1 Assumptions

To perform the tasks in this section, we are making the following assumptions: 1. You have followed through and understood Section 6.5, Building Oracle PDK-Java Portlets with Oracle JDeveloper . 2. You built a portlet using the wizard and successfully added it to a page.

7.2.7.2 Introduction to Portlet Security Features

This section introduces the major features that are available to secure your portlet providers.

7.2.7.2.1 Authentication When a user first logs in to an Oracle Portal instance, they

must enter their password to verify their identity and obtain access. This authentication is performed by OracleAS Single Sign-On Server server. Refer to Section 7.2.7.3, Single Sign-On for more information. Once the user’s identity is passed to the provider in shown requests, the provider code has access to the authenticated users identity from the PortletRenderRequest that is available from the HttpServletRequest object as follows: 7-36 Oracle Fusion Middleware Developers Guide for Oracle Portal PortletRenderRequest pr = PortletRenderRequestrequest.getAttribute HttpCommonConstants.PORTLET_RENDER_REQUEST; String userName = pr.getUser.getName; Refer to Oracle Fusion Middleware Administrators Guide for Oracle Portal for more information.

7.2.7.2.2 Authorization Authorization determines if a particular user may view or

interact with a portlet. Oracle Portal provides the following two types of authorization checking: ■ Portal Access Control Lists ACLs: After a user is authenticated by OracleAS Single Sign-On Server, Oracle Portal uses ACLs to determine what privileges that user has to perform actions on portal objects, such as folders and portlets. The actions available to a user can range from simply viewing an object to performing administrative functions on it. If a user does not belong to a group that has been granted a specific privilege, Oracle Portal prevents that user from performing the actions associated with that privilege. Refer to Section 7.2.7.4, Oracle Portal Access Control Lists ACLs for more information. ■ Programmatic Portlet Security: You can also implement your own security manager programmatically. Refer to Section 7.2.7.5, Portlet Security Managers for more information.

7.2.7.2.3 Communication Security To this point, we have covered user authentication

and authorization, which do not check the authenticity of messages received by a provider. The following measures can be used to properly secure communication between a portal and a web provider: ■ Oracle Portal Server Authentication restricts access to a provider to a small number of recognized machines. This method compares the IP address or the host name of an incoming HTTP message with a list of trusted hosts. If the IP address or host name is in the list, the message is passed to the provider. If not, it is rejected before reaching the provider. Refer to Section 7.2.7.6, Oracle Portal Server Security for more information. ■ Message Authentication uses a shared key to assert the Portal client identity and to prevent message tampering. Refer to Section 7.2.7.7, Message Authentication for more information. ■ Message Encryption encrypts message contents. Refer to Section 7.2.7.8, HTTPS Communication for more information. ■ User Input Escape causes Oracle Portal to escape any user input strings and treat them as text only to protect against XSS attacks, where an attacker attempts to pass in malicious scripts through user input forms. Refer to Section 7.2.7.10, User Input Escape for more information. For more information about communication security, refer to the Oracle Fusion Middleware Administrators Guide for Oracle Portal.

7.2.7.3 Single Sign-On

Portlets act as windows into an application. They display summary information and provide a way to access the full functionality of the application. Portlets expose application functionality directly in the portal or provide deep links that take you to the application itself to perform a task. An application may need to authenticate the user accessing the application through the portlet. Following are the possible application authentication methods: Enhancing Java Portlets 7-37 ■ Section 7.2.7.3.1, Partner Application . In this case, the application user is the same authenticated user used by Oracle Portal. ■ Section 7.2.7.3.2, External Application . In this case, the Oracle Portal user is different from the application user, but the application user name and password are managed by the Oracle Portal user. ■ Section 7.2.7.3.3, No Application Authentication . In this case, the communication between provider and Oracle Portal is not protected at all. For more information about Single Sign-On, refer to the Oracle Fusion Middleware Administrators Guide for Oracle Portal.

7.2.7.3.1 Partner Application A partner application is an application that shares the

same OracleAS Single Sign-On Server as Oracle Portal for its authentication. Thus, when a user is already logged in to Oracle Portal, their identity can be asserted to the partner application without them having to log in again. Partner applications are tightly integrated with OracleAS Single Sign-On Server. When a user attempts to access a partner application, the partner application delegates the authentication of the user to OracleAS Single Sign-On Server. Once a user is authenticated that is, has provided a valid user name and password for one partner application, the user does not need to provide a user name or password when accessing other partner applications that share the same OracleAS Single Sign-On Server instance. OracleAS Single Sign-On Server determines that the user was successfully authenticated and indicates successful authentication to the new partner application. The advantages of a partner application implementation are as follows: ■ Provides the tightest integration with Oracle Portal and OracleAS Single Sign-On Server. ■ Provides the best single sign-on experience to users. ■ Provides the most secure form of integration because user names and passwords are not transmitted between Oracle Portal and the provider. The disadvantages of a partner application implementation are as follows: ■ The application must share the same user repository as Oracle Portal even though the applications user community may be a subset of the Oracle Portal user community. While worth some consideration, this issue is a minor one because the portal pages that expose the application can be easily restricted to the applications user community. ■ The application can only be tightly integrated to one or more OracleAS Single Sign-On Server instances if they share the same user repository. ■ The application must be written such that it delegates authentication to OracleAS Single Sign-On Server. ■ You must have access to the application source code.

7.2.7.3.2 External Application An external application uses a different authentication

server than Oracle Portal. The application may use a different instance of OracleAS Single Sign-On Server than that used by Oracle Portal or some other authentication method. However OracleAS Single Sign-On Server does store the user name and password of the external application for that user. This means that when a user is already logged into Oracle Portal, they will be logged into the external application without having to type in their user name or password.