Manchester Computing

IS Programme

Manchester Computing

The University of Manchester

Oxford Road

Manchester M13 9PL

TECHNICAL EVALUATION REPORT
Gateway Project
Circulation / Portal Technologies Focus Group, PAT, EPB, TIC
Date/Version / Version 1.0 (last amended 15th August 2005)
Enquiries / Joni Purmonen, Gateway Technical Team Leader (63972 or )
Action / For comments and consideration.

1INTRODUCTION

This report aims to answer all technical requirements identified by the Portal technologies Focus Group[1] for Oracle Portal (Oracle Portal 10g Release 2) and JASIG uPortal (2.5 and 3.0) and to provide background information to support making the decision on the next step forwards in Gateway project.

Sections 2-6 can be highly technical at times, for any questions please do not hesitate to get in touch with Joni Purmonen. There is a summary of the main findings of the technical comparison provided in the section 7 in the end of the document written in a way which requires no special technical knowledge of the portal products and technologies.

The sources of this information include site visits to, and discussions with other HE institutions, technical documentation from various sources, testing with the application and expert help. Consultancy help was considered for Oracle Portal related questions, but this failed[2]. Fortunately Peter Jackling, Oracle Architecture Specialist, joined the university and he has been a great help in answering the Oracle related questions for which I am very grateful. Also an Oracle Portal training course was attended[3].

1.1GENERAL COMMENTS ON COMPARING ORACLE PORTAL AND UPORTAL

Comparing these two products is like comparing apples and oranges because Oracle Portal is a “complete, pre-integrated out-of-the-box portal solution”[4] whereas uPortal is a framework for portal development with flexible architecture and open class structure. In practice this means that uPortal can be integrated with numerous different deployment environments from databases, application servers, and authentication services and so on while Oracle Portal comes with integrated database, authentication system, and application server and so on.

Both products are actively developed so a detailed comparison of technical functions is not an ideal measure of them. By the time the solution has been implemented, which could take a year or more, the specifications have been changed in both products bringing out new products responding to market demands and developing standards. As a rule of thumb it can be said that uPortal will always going to lead in HE specific functionality while Oracle Portal is going to be better at integrating Oracle business products.

1.2SCOPE OF THE DOCUMENT

These technical requirements were identified by the cross campus Portal Technologies Focus Group and were formed on an abstract level without any consideration to the possible solutions that are measured against these requirements. For this reason they may be phrased in a way that the answers have been difficult to find. Also, the question is not as much “can this solution do a, b and c”, but how this kind of functionality can be achieved and if this way suits University’s technical requirements.

This document does not address cost issues related to support, development and maintenance. It also leaves out the discussion of portlet functionality and rather focuses on the portal framework issues. Infrastructure requirements for uPortal are answered in a separate document.[5]

2AUTHENTICATION AND AUTHORISATION

2.1AUTHENTICATION

2.1.1The portal should be capable of authenticating against the University LDAP based authentication service (eDirectory). Direct authentication against eDirectory is preferred. HIGHLY DESIRABLE

Oracle: Can authenticate against eDirectory via a "filter" which sits in between Oracle Internet Directory (OID) and eDirectory as is done with Student Services Centre portal. No direct authentication between Oracle Portal and eDirectory due to OID having own proprietary extensions to the LDAP.

The authentication for all services exposed via the portal has to be made through the Oracles own Single Sign On server. What this means in practice is that in order to expose services such as web mail or WebCT, these servers would need to be made “Oracle Single Sign On aware”, that is, authenticate against Oracle SSO server rather than eDirectory. This would require significant and highly skilled in-house custom coding for the non-Oracle backend services.[6]

uPortal: is capable of authenticating against LDAP/eDirectory.

2.1.2The portal should provide secure authentication to ensure that passwords are NOT passed in clear text across the network. ESSENTIAL

Both options provide possibility to handle authentication via SSL (HTTPS) between client and the web server.

Oracle:Authentication can be done via SSL from client to the web server. Password between Oracle portal and OID and then eDirectory is done in plain text. Further authentication is done using Oracle SSO ticket rather than username and password.

uPortal: In addition to supporting encryption between the client and the web server, uPortal supports encryption between the uPortal instance and the LDAP server.[7]

2.1.3Portal authentication should support chaining (i.e. multiple authentication authorities). DESIRABLE

Oracle: Stores all authentication credentials in OID and the preferred approach from Oracle is synchronising rather than chaining authentication.[8]

uPortal:Done with a special class org.jasig.portal.security.provider.UnionSecurityContextFactory which allows chaining multiple authentication authorities such as LDAP, CAS, local database, in practice any desirable combination since the authentication chaining is done via a pluggable classes.[9]

2.1.4The Portal should provide the capability to support certificate based authentication in the future. DESIRABLE

The Oracle Identity Management System includes support for PKI certificates.UPortal supports pluggable authentication classes but no reference cites doing certificate based authentication was found at this stage.

2.1.5The Portal must have the capability of supporting pass through of user credentials to backend applications. Pass through of credentials should enable backend applications to access the University Single Sign-On framework (Yale CAS is the preferred infrastructure). HIGHLY DESIRABLE/ESSENTIAL

Oracle: Does not allow to cache username and password in the session, but rather stores the Oracle SSO session ticket and passes that to backend applications. Applications which do not authenticate against Oracle SSO will not work with single sign on but require a separate login.

CAS only supported if Oracle is a “backend service” and Oracle SSO is made to think that the CAS session ticket is actually the password of the user.[10]

uPortal: Allows both caching the username and password in the session thus enabling single sign on to backend applications by passing them through. Also supports caching session tickets such as CAS or other single sign on services and then passing them through to backend applications.

2.1.6The Portal must provide secure mechanisms for transferring user credentials between backend services. ESSENTIAL

Answered above.

2.2AUTHORISATION

2.2.1The portal must support role (attribute) based authorisation for the selection of user interface components e.g. default pages, portal tabs, portlets, portlet functionality. ESSENTIAL

See also answer 4.3.1 from user layout point of view.

Oracle: Access control lists (ACL) are used throughout to manage user and group privileges on portal objects (pages, styles, items, portlets, etc.)[11]. Unclear how this would be done on group data based on LDAP.

uPortal: PAGS, Person Attribute Groups Store[12] is a powerful mechanism to handle role/attribute based authorisation. UPortal can take an entry in LDAP and dynamically use it as a group attribute to apply authorisation to tab, portlet and portlet functionality level. Distributed Layout Management can be used to determine layout of the portal in great detail based on LDAP attributes and other group data.

2.2.2The portal should provide the capability for role membership to be mandatory (i.e. users cannot remove themselves from roles such as staff, PG, UG), optional (i.e. users can subscribe to additional roles such as the 'canoe club') and mixed. ESSENTIAL

Both solutions support this in different technical way with many practical similarities. In Oracle portal comes with “seeded” users and groups and an owner of an object can grant privileges to other users or groups to allow them to interact with the page or object while in uPortal group data held in LDAP can be dynamically used to define the mandatory roles and portals own permission structure for optional ones.

2.2.3The portal should provide the capability for a large number of configurable roles. ESSENTIAL

Oracle: The Portal is fully scalable and reference sites available to show large and complex user deployments (including Oracle themselves). The scalability will depend on the architecture design and guidelines are provided to assist with this.

uPortal: Groups and Entities structure coupled with PAGS (mentioned above) provide flexible way of defining a large number of configurable roles.

3BACKEND INTEGRATION

3.1.1The portal should aim to accommodate ALL university backend applications/systems e.g.WebCT, Library systems, HR, Student records, Faculty-based systems, service unit based systems etc.). ESSENTIAL

Since the University has a variety of systems and since we need to future proof systems as yet unknown, the only reliable way to achieve this is for the portal to support standards based application to application communication. In many ways the ball is in both corners: portal needs to adhere and accommodate these standards as well as the backend applications need to have exposed API’s, enabled web services and other means to integrate with the portal.

Both systems accommodate various standard and proprietary ways of achieving this. However, integration should not only be looked at being about transfer of data, but also the way how authentication and authorisation is done and the differences between these two solutions have been detailed in the previous section.

3.1.2Portal interfaces with backend systems should be technology neutral. The portal should support standards-based communication, such that the technology used to develop backend applications is irrelevant. HIGHLY DESIRABLE

Both options support standards based portal to backend application web service based communication protocols.

3.1.3The portal should be able to interface with XHTML, XML and web services. ESSENTIAL

Both options can interface with XML and Web Services and with XHTML via varying proxying methods or other HTTP based methods.

3.1.4The portal should be able to interface with direct application programming interfaces (API's). Many applications offer an API for development of custom functionality. These API calls can be made remotely and from within the portal layer. HIGHLY DESIRABLE

Both solutions offer ways to utilise remote application API calls programmatically. This is more of a portlet development, than portal framework issue.

3.1.5The portal should enable portlet to portlet communication e.g. an action in one portlet triggers an action in another portlet. DESIRABLE

Both solutions accommodate this.

3.1.6The portal should support the Java Specification Request (JSR) 168 portlet standard. This would enable investment protection by allowing portlets to be developed to a standard and they transfer to an alternative portal framework if necessary. HIGHLY DESIRABLE

Oracle: Support for JSR 168 has been promised for a long time and it has available via a separate downloadable adapter. The latest version 10g r2 (9.0.4) states that JSR 168 portlets are supported via WSRP adaptor to a separate JSR 168 portlet container. WSRP consumption is not yet supported.[13]

uPortal: in versions 2.* JSR 168 portlets were supported via an adapter (portlet to channel) and the native uPortal channel as a primary. In version 3.* this has been turned around and JSR 168 portlets are supported natively using Apache Pluto portlet container (which is the reference implementation of JSR 168 standard) and uPortal channels will be supported using an adapter (channel to portlet).[14]

uPortal supports both WSRP consumption and can act as a WSRP producer.

4USER INTERFACE

4.1DEVICE SUPPORT

4.1.1The portal must be capable of separating style (page layout and presentation) from content (text, images, multimedia, etc). By doing this, it should be possible to ensure the portal delivers SENDA compliant pages, a branded interface consistent with other university web-based services and content to a range of devices e.g. different web browsers, straight to the desktop, mobile devices, webTV etc. ESSENTIAL

Oracle: Portal uses HTML and tables for positioning of the portlets. While programmer will have control over what happened in a custom made Java portlet, portal framework will wrap this inside a HTML table cell, or several layers of table cells.[15] Thus style is not separated from the content.

Experiences from re-branding the student services centre portal also indicate that changing page layout and presentation is demanding and not flexible.

uPortal: Presentation layer is based on XML/XSL transformations and is separated from content. This allows ultimate flexibility of control over the presentation layer, though knowledge of XSLT is required and the default layouts are done using tables for positioning rather than CSS positioning. Many HE institutions have redesigned uPortal presentation layer to meet 508 compliancy and SENDA requirements.[16]

4.1.2The portal should be capable of detecting the device request the content thus allowing different transformations of content to be made on the server. DESIRABLE

Both solutions support this.

4.2PORTAL INTERFACE REQUIREMENTS

4.2.1The portal should be accommodate a flexible navigational structure (page menus or page tabs) with an element of hierarchical structure e.g. tabs within tabs. DESIRABLE

Neither solution offers this out of the box.

Oracle: The look and feel navigation is usually driven by template files. These can either be seeded templates or custom developed ones. These incorporate some basic rules to ensure the page can make use of the underlying security and configuration model. The basic hierarchy in the Portal is maintained and this provides the navigational structure of the page. This can include tabs within tabs and page menus. Note the portal usually includes a full text search capability that supplements the page navigation.

uPortal: Page menus can and have been be built in some uPortal installations currently in production in other HE institutions[17]. Tabs within tabs can be done using XSLT.

4.2.2The portal should be able to accommodate client side user interface functionality e.g. DHTML, javascript code libraries. The portal should be able to support internationalisation of content. HIGHLY DESIRABLE

There is built in internalisation support in both products where either users or the admin can choose a language and general internationalisations standards.

The user interface functionality is taken to mean that if there is a requirement for a portlet to insert JavaScript into the header part of the whole page, how can this be achieved.

Oracle: No dynamic way to achieve this (adding JavaScript to the page header during run time), though access to CSS and templates exist.

uPortal: Due to separation of content from the presentation via XML/XSL client side functionality can be achieved programmatically.

4.2.3The portal should enable administrator definable skinning for specific users. DESIRABLE

Both solutions support this.

4.3PAGE REQUIREMENTS

4.3.1The portal must have the capability for an administrator to define compulsory portlets, optional portlets, restricted portlets and any combination of these on a portal page. ESSENTIAL

Oracle:Oracle Portal treats portlets as provider objects on a page and users / groups are assigned permissions on these objects. This will determine if an individual can see and interact with a portlet. Not sure if that will meet the above definition.

uPortal: Distributed Layout Management, DLM, in uPortal version 2.5+ allows administrators to define compulsory portlets, optional portlets, restricted portlets per role or group data basis.

4.3.2The portal must have the capability for portlet positioning, sizing and within iframe to be defined by an administrator (ESSENTIAL) and by a user (DESIRABLE).

Oracle:In theory this is achievable, but there are a lot of issues being raised on the Oracle Support site. The recommendation is to use webclipping and omniportlet instead. The configuration at the user level appears to be limited (colour and border options).

uPortal: Positioning can be done via Layout Management and portlet sizes can be fixed on column basis. In practise universities tend to fix whole tab of portlets or a column rather than mixing the administrator and user defined positioning and sizing.

4.3.3The portal must have the capability for administrators to define page templates with predefined portlets, positioned and sized. Templates should be assignable to roles. Administrators and users must be able to return a users page layout to a default/template state. ESSENTIAL

Focusing on templates in this answer, other parts answered above.

Oracle:The template and item rules will determine how much scope the users have for changing things. Administrator will maintain the default layout and the rules, they would not normally reset individuals preferences

uPortal: Uses a “template user” (a user account for which you can build a template and this template is then cascaded down to a given group) to build templates based on group data. For instance “student” template user template would be cascaded to all users in “student” group, and these groups can be mixed (i.e. a user who has access to both student and staff content).

4.4PORTLET REQUIREMENTS

4.4.1The portal should be capable of supporting portlets with minimise, maximise, full-window (within current browser and in new browser), add, remove actions. Portlet functionality should be configurable by an administrator. HIGHLY DESIRABLE

Both support minimising, maximising, adding and removing portlets. UPortal supports detaching of the portlet into a separate window as well.

4.4.2The portal should support portlets that accommodate all standard types of content e.g. text, images, tables, forms, multimedia. ESSENTIAL

Both portal solutions accommodate this.