Login to Oracle Portal as a portal user that has a mapping stored in the SSO Server.
| Last Updated: | November 28, 2003 |
| Status: | Production |
| Version: | PDK Release 9.0.4 |
This document describes how you can use the PDK-Java to integrate an external application with Oracle Application Server Portal. External applications are stand alone web applications, which typically have their own concept of a user's identity. This identity does not necessarily map directly to the same user's identity in OracleAS Portal, as defined by the Single Sign-On (SSO) Server. Such applications are integrated with the SSO Server as 'External Applications'. For each user, the SSO Server stores user name mappings, passwords and any other credentials required to authenticate the user in each external application. This allows Portal to hand a user over to an external application transparently, without requiring them to log in themselves.
For even tighter integration with OracleAS Portal, an external application can be exposed as a web provider using the PDK-Java, so that it may be accessed from a portlet on a Portal page. This document demonstrates this style of integration by looking at an example web application, "Flights of Fancy", and describing how its integration with OracleAS Portal is performed. The Flights of Fancy application displays a list of flights for a user and provides links to display the details of a flight.
The complete Java source code for this example partner application is included in the PDK-Java distribution, under the directory src/oracle/portal/sample/v2/devguide/externalApp. The files are:
This section contains instructions for installing the Flights of Fancy sample external application. It covers how to set up the Server to run the Fancy Flights application and how to register the external application and provider with Oracle9iAS Portal.
http://<host>:<port>/jpdk/servlet/ExternalAppFlights
http://<host>:<port>/jpdk/providers/external
The following execution scenarios show the integration of the Fancy Flights application with Oracle Portal and the SSO Server. All these scenarios assume that the Web Provider has been registered in Oracle Portal with the external application ID associated with it and a page with a portlet from this provider exists.
Login to Oracle Portal as a portal user that has a mapping stored in the SSO Server.
The following is the process flow that is involved as depicted in the above diagram.
http://loginserver.domain.com/pls/ls/ls.wwsso_app_admin.fapp_process_login?p_app_id=103&p_url_name=FlightDest&p_url_value="http://myserver.com/jpdk/servlet/ExternalAppFlights?FlightAction=details"
This section takes a look at how the Flights of Fancy application is implemented and how it internally handles the above execution scenarios.
The security system consists of a set of users, passwords, and a cookie which is set up when login is successful. This cookie is used to determine if the user is logged in or not. The cookie contains the user name, and this is used to determine who is logged in. To be truly secure, the model would be much more complex, however for this example it is not necessary, nor does it change the scenario in any way.
The table below shows the valid users, passwords, and the cookies which are created upon successful login. Since this is an example, these users, and passwords are hard coded within the code base.
| User Name | Password | Cookie |
| user1 | pass1 | flightcookie=user1 |
| user2 | pass2 | flightcookie=user2 |
| user3 | pass3 | flightcookie=user3 |
| user4 | pass4 | flightcookie=user4 |
| user5 | pass5 | flightcookie=user5 |
The table below explains the security model implemented.
| If | Then |
| No cookie exists for the incoming request | Display the Login Screen. |
| A cookie exists, but the user in the cookie is invalid | Display the Login Screen. |
| A cookie exists, and the user is valid | Display the requested Screen. |
There are 3 classes in the example code. It was designed to allow for the least amount of changes necessary to complete the provider conversion, while not making assumptions about what would be needed to do the conversion. Therefore, the screens and actions were put into one class. The login routines, and login screen are in their own class, and the Servlet code is in its own class. The idea is that by separating these objects, they could be reused during the building of the provider.
The ExternalServlet class performs the required actions for a Servlet. It receives the request from the listener, and then calls the process routine in FlightDispatch. It can handle both Post and Get requests from the browser.
The FlightDispatch class performs all of the significant work for Flights of Fancy, which includes displaying both the List screen and the Details screen, and the routing of requests. This can be thought of as the main objective of the system. Anything that is done, routes through this class. It performs the following tasks:
The ApplicationLogin class handles all functions dealing with user login, or inspecting a request to determine if the user is logged in. There are two main methods in this class. This first is the Display Login method which displays the login screen. The second is the perform login routine which checks user/password validity, and creates the login cookie.
The overall approach taken when exposing the application as a web provider was to make as few changes to the application as possible, and to make sure the application still ran as a stand alone servlet. Creating new screens was also undesirable, as doing so would create two code bases to maintain. Therefore it was important to be able to adapt the current screens to properly perform in both the provider environment, as well as the application environment. The following subsections examine this conversion process in more detail.
The first task is to create a Web provider that displays a portlet. To accomplish this, remove security from the servlet, and then set the Web provider up to display the List Screen. Any non secure screen can be used to display the portlet. This scenario uses the Default Provider model of the Web provider, as this required the least amount of coding, and would lend itself well to the security model used in this application. This part could be skipped, however it is helpful to get the portlet display created first, and then the External Application. Once you have displayed the desired portlet, you can add the security back in, and create the External Application.
In this case, the task was simple. Since Flights of Fancy handles all of its own rendering, the portlet renderer, FlightRenderer, does nothing more than call FlightDispatch, and some header and footer utilities provided by the PDK-Java.
The final step of creating an External Application Web provider involves creating an Application provider package, and registering the External Application with Oracle Portal. To support the security model, the example application will use the username and password sent in the ExternalPrincipal object during initSession() to perform the login.
Extend ProviderInstance to support logging in of the application. initSession() is the method which performs logging in. Simply extend ProviderInstance and rewrite initSession() to perform the proper login. Since the login routines for the example application are held in a separate class, this class can be used to perform the real login, and thus keeping the security localized to one object. Note: This example uses two cookies. One is the original application's cookie and the other is the cookie used to maintain the servlet session. Two cookies are required for this example because the original application does not use the servlet session. Instead it uses it's own cookie. However, the PDK-Java requires a servlet session so a second cookie (for the servlet session) must be created.
Change the XML file to account for the extended ProviderInstance. This is done by changing the value of the providerInstanceClass tag in the XML file. For this example, the ExternalProvider will now be called instead of ProviderInstance.
Add a routine to the ApplicationLogin called getApplicationCookie to retrieve the cookie for the user. This method uses the external application user mapping (user/password + form field names & values) to determine if the OracleAS Portal user is allowed to access this application.
Since for each screen to be displayed, the ApplicationLogin is used to check the login, the constructor needs to be overloaded to accept the PortletRenderRequest instead of the HttpServletRequest, and HttpServletResponse as it was designed in the stand alone method.
Since Portal is communicating with the External
Application Web Provider, it is OracleAS Portal which is managing
the cookie needed by the application. To establish sessions at the
browser, the browser needs to login to the application. This is done
through the SSO Server. To accomplish this, all of the links in the
List screen (displayed as a portlet) are wrapped with a call to the
SSO Server External Application Login processing routine. The SSO
Server parameter sent by the Web Provider Framework is used to render
this link. It must pass the URL name, and URL value expected as part
of the link. The parameterizeLink (see API documentation for PortletRendererUtil)
method can be used to put this link together. The code snippet here
demonstrates the use.
// pr is the PortletRenderRequest.
///server is the External Applications URL.
if (pr != null)
{
String loginURL=pr.getRenderContext().getLoginServerURL();
String str1 = PortletRendererUtil.parameterizeLink(loginURL,
"p_url_name=" + FLIGHTDEST);
hrefValue = PortletRendererUtil.parameterizeLink(str1,
"p_url_value=" +
PortletRendererUtil.encodeParameter(server.toString(), pr));
} |
| Revision History: |
|
| Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065, USA http://www.oracle.com/ |
Worldwide Inquiries: 1-800-ORACLE1 Fax 650.506.7200 |
Copyright and Corporate Info |