OracleAS Portal Developer Kit (PDK)
Understanding the Federated Portal Adapter

Introduction

This article describes the Federated Portal Adapter and its use with OracleAS Portal. It is assumed that the reader is familiar with the concepts of database and Web providers.

Distributed Portal Systems - The Problem

Prior to OracleAS Portal version 3.0.9 all database providers accessed from a portal instance had to be on the same physical database server that contained the portal instance. This is not ideal as the load on the database server can not be distributed. Consider a scenario where a portal is created to allow a corporation to expose portlets to several of its internal systems using database portlets. Prior to OracleAS Portal 3.0.9 the portal instance and all of the applications had to be installed on the same database server instance. Not only does this cause scalability problems, but it also introduces a single point of failure.

In OracleAS Portal version 3.0.9 it is possible to distribute database portlets across database servers. To do this, the user must register portal 'nodes' with each other to create a database link between the 'nodes'. One issue with this architecture is that the database links between the portal instances use Net8, Oracle's proprietary networking protocol. This means that the portal nodes can not function beyond a firewall. Also, portal node registration is 'symmetric', i.e. if there are three portal nodes, PortalA, PortalB & PortalC then PortalA had to register PortalB & PortalC, PortalB had to register PortalA and Portal C, etc. and this can soon become unmanageable.

The Solution - Federated Portal Adapter

OracleAS Portal communicates with Web providers via HTTP and SOAP and using PDK-Java, users can easily develop providers in Java that receive SOAP messages and respond accordingly. However, providers do not have to be written in Java. Providing they receive and respond to SOAP messages sent by OracleAS Portal, providers can be written in any language.

The Federated Portal Adapter is a module in the portal instance ( written in both Java & PL/SQL) that receives SOAP messages for a Web provider, parses the SOAP and then dispatches the messages to a database provider as PL/SQL procedure calls. In effect, the Federated Portal Adapter makes a database provider behave exactly the same way as a Web provider, allowing users to distribute their database providers across database servers. All remote providers can be treated as Web providers, hiding their implementation (database or Web) from the user.

The main difference between database providers and Web providers is that typically, database providers use a portal session within the code. So, as part of the Federated Portal Adapter a portal session is created on the remote portal instance. The SOAP messages were extended to contain enough information to create a session on the remote portal instance (see Security Issues below) which means that the user in the remote portal must be the same user as in the local portal.

For example, if 'UserA' is running in 'PortalA' and is using a provider on 'PortalB' via the Federated Portal Adapter, a session is created in 'PortalB' for 'UserA'. Typically this means that 'PortalA' and 'PortalB' would share the same Login Server. However, an alternative arrangement is that they have separate Login Servers but the Login Servers share the same name server, i.e. the two Login Servers may share the same OID instance.

Security Issues

As mentioned above the Federated Portal Adapter creates a portal session in the remote portal based on the information passed in the SOAP message. This introduces a security issue since it may be possible to replicate these SOAP messages and create sessions for any user on a portal and then access the portal as that user.

To avoid this an encryption key is shared between the two portals and part of the SOAP message is encrypted using that key. Only if it can be decrypted by the previously shared key can the requested private portal session be created, otherwise a PUBLIC session is created. Show messages, which do not send SOAP, are protected by the encrypted cookie which is created by the initSession SOAP message. Using this method the Federated Portal Adapter can safely trust the incoming SOAP message and create portal sessions in the portal instance without opening the portal to hackers.

If it is known that the portal instance will only be accessed via the Federated Portal Adapter from other portal instances, security can be enhanced by configuring the listener to restrict access from machines other than the known portal instances.
 

Updating Portlets to Work via the Federated Portal Adapter

Database providers written prior to OracleAS Portal 9.0.2 will not work when accessed via the Federated Portal Adapter if the:

• Portlet contains relative links
• Portlet is customizable

Relative Links

When using the Federated Portal Adapter, all links within a portlet should be absolute links, i.e. 'http://host:port/images/foo.gif' rather than relative, '/images/foo.gif'. This is because the request is processed by the parallel page engine on the local portal instance. Relative links are interpreted as relative to the local portal and not to the portal containing the portlet - and thus would typically fail.

Customizations

Customizations for database providers and Web providers are processed differently. For Web providers the customization form is submitted to the parallel page engine of the local portal, which then calls the portlet again, the customizations are saved and the page is redirected appropriately. Since database providers accessed via the Federated Portal Adapter are effectively Web providers then this method of customization should be undertaken for these providers. A public API is provided (WWPRO_API_ADAPTER) to help to do this.

Updating providers

Database providers developed prior to OracleAS Portal 9.0.2 will be upgraded automatically to work with the Federated Portal Adapter. Pages exposed as providers can also be accessed via the Federated Portal Adapter.

Summary

The Federated Portal Adapter allows database providers to be accessed as though they are Web providers. This allows database providers to be distributed across database servers using SOAP and HTTP.