Overview  

The University of Virginia implementation of uPortal is known as MyUVa.  It is currently based on uPortal 2.5.1.  All student, staff and faculty are allowed to use MyUVa but the main focus has been on entering and first-year students.  All incoming students are directed to use MyUVa and much of the incoming student information and activities are coordinated through the portal.   However, there is a growing interest in Sakai and OSP at the Unversity and Sakai integration into our portal was identified as a desirable strategy.

Sakai Integration into MyUVa: What It Looks Like

The current implementation appears like this to users (actually this is a portal administrator login):
You will notice that Sakai is contained entirely in a single tab labelled "Collaborations", and that the site navigation appears as a second set of tabs.  We felt that this gave proper separation between sakai and the portal contexts, but still gave it the sense of integration.  This model is also fits best with the portlet/iframe integration model.
A few other things that you may not have noticed:

• The Collaborations tab has a single portlet on it.
• The worksite tabs are generated by the portlet.
• The rest of the Sakai layout sits in an iframe generated by the portlet.
  • This models the use of iframes in Charon, the Sakai portal.
• Authentication into Sakai is transparent to the user.
  • Load balancing complicates shared authentication.
• Because our Sakai is in pilot (and our portal is not) only pilot users see the "Collaborations" tab.
  • This is accomplished via the uPortal Groups infrastructure (GAPS), a custom PersonAttributesDAO, Sakai webservices and DLM.
  • We are using DLM as a layout manager, but this should work with ALM too.
• Sakai is running as a portlet inside uPortal, but there is no portlet "decoration" around it.
  • This required a trick using a portlet/channel parameter and a modified theme stylesheet
• The javascript in Sakai puts some constraints on how the iframe integration is implemented

Background

uPortal Configuration

We are currently running uPortal 2.5.1.   We use the Distributed Layout Manager (DLM) and user layouts are primarily composed of DLM fragments, although users are allowed to customize.  We make extensive use of groups and layout owners to control layout via DLM.

The webapp container is apche tomcat 5.0, front-ended by apache httpd 2.0 via a mod_jk 1.2.x connector.  Each physical server has one httpd jk-connected to a single tomcat instance.  We make extensive use of Apache httpd for url-mapping and delivery of static content.

There is a hardware loadbalancer (Cisco LocalDirector) in front of the Apache servers.  

See Appendix: uPortal Configuration Details

Sakai Server Configuration

Our Sakai implementations are version 2.1.2.  The sakai servers are physically separate boxes from the uPortal servers.   It was desired to load balance across multiple boxes to provide for future scaling.  Each production box runs a single tomcat container with a single Sakai instance.  Currently, in pilot, we have two applications servers for Sakai and one database server on a separate machine (currently MySQL 5.0).  We have apache httpd running on each server, but this is only for testing and auxillary use.   We do
not use the local httpd when integrating the Sakai tomcat instances with uPortal.  We use an AJP13 connector (mod_jk) directly from our uPortal instance instead.

Loadbalancing

Some background and discussion is needed on loadbalancing to fully understand the issues in integration.  We use a front-facing hardware loadbalancer

  In this diagram there are three uPortal servers and two tomcat servers.  The uPortal servers have an Apache httpd server mod_jk-connected to a single tomcat
 instance running uPortal.  The Sakai servers have single tomcat instances running Sakai.  These are mod_jk-connected to the same Apache httpd's on the uPortal servers. They differ from the local mod_jk connectors in that they are load balancing connectors.  So each front end Apache httpd is mod_jk connected to a single uPortal tomcat locally, and connected to two load balanced Sakai tomcats remotely.  This provides loadbalancing for both the uPortal Tomcat and the Sakai servers.

Integration

When discussing "integrating" uPortal and Sakai it is necessary to define what you mean and temper that with what you can accomplish.  Our integration efforts focussed on bringing sakai sites into the uportal layout, make it seem like "part of the portal". 

Integration Goals

1. All authentication is done through the portal
   • PubCookie and local username/password authentication must be supported
2. Collaborations appear all on one tab*
3. As we are in pilot, the Collaborations tab appears for select pilot users only
   * I guess this wasn't so much a goal as a compromise

Integration Strategy

We investigated a few integration strategies:

1. WSRP
   • Investigating WSRP, we felt it was probably the strategy with the most long-term benefits, but it lacked maturity on both the Sakai and uPortal side, and it also involved the most work.
2.  Gallery mode
   • Gallery mode in the sakai portal (Charon) looked at first to be a quick win, but aspects of it rendered it unworkable in a portal setting (see SAK-3120).
3.  Portlet and iFrame
   • Chuck Severance posted a proof-of-concept JSR-168 portlet to the sakai-dev list which served as the model for this approach. 

In the end we elected to go with the portlet/iframe integration strategy. This held the most promise to us because:

• it provided control over the rendering of worksite navigation
• it closely followed the rendering model of the charon portal (worksite iframes) promising robustness

In addition there were a few gotcha's that we ran into that made us adjust our integration strategy and/or implement workarounds which we will discuss later

• Javascript Hell
• Load balancing vs. webservices
• Load balancing vs. authentication

Portlet/iFrame Integration Strategy

 Implementation

 The Good, The Bad, The Ugly and The Really Ugly

Below are the implementation details and a few explanation of

 

 The Sakai Portlet

At the time we first embarked on this journey (Fall of 2005), Chuck Severance had introduced a JSR-168 portlet [references?] which utilized webservices and iframe integration.  We used this as starting point for our integration efforts.

The primary modifications to Chuck Severance's portlet was to rip out the login functionality and to introduce custom navigation.  In addition some machinery for our authentication was introduced.  All the authentication and session-binding occurs behind the scenes. 

Shared uPortal Authentication

All authentication is done through the uPortal instance.  There are various flavors of authentication currently implemented (PubCookie, local uPortal users and local Sakai users).

Authentication to Sakai is done via an authentication token encrypted using public key encryption.  The token is passed as parameter (or as a cookie, although that mechanism is being deprecated) where a servlet filter on Sakai reads its, decrypts it using its private key, and establishes session as the user that is contained in the encrypted package.   Also passed in this authentication packet is the uPortal server on which the user is logged in.  The servlet filter calls back to a servlet on the portal side to verify that the session is legitimate and also to "register" the SakaiSession on the portal.  ( More on this later ).  After verification, the servlet filter sets the REMOTE_USER environment variable and container authentication in Sakai takes over.

Use of uPortal Groups and Permissions

Because we are in pilot, currently the sakai portlet is only included in the layout of specific pilot users.  This is accomplished via DLM and the Groups and Permissions infrastructure in uPortal.  A PersonAttributeDAO is used to call a sakai webservice to see if the current user is a sakai user.   If they are a person attribute it set and that is mapped to a PersonAttributeGroup (PAG) in uPortal.  DLM is then configured to deliver a single tab with the Sakai Portlet.

 

Javascript Madness

Cross-domain iFrames can wreak havoc with javascript-heavy pages.   This is especially true of FCKEditor and HTMLArea which figure largely in several Sakai tools.  By "Cross Domain", we are talking about javascript domains. [ link to explanation of javascript domains and cross-site scripting ].  Javascript domains are by default the apparent host address of the webpage that delivers the javascript.  So if the webpage in question is e.g. http://www.bleh.blah.edu, then the domain is www.bleh.blah.edu. 

[ cross-site scripting restrictions ]

http://www.mozilla.org/projects/security/components/same-origin.html

• attempts to change the domain (origin) of all the javascript
• the hair-tearing experience with HTMLArea and FCKEditor
• the solution: use Apache JKMounts to map Sakai into the same "domain" as MyUVa

 

Apache Configuration

Because we need to bring the sakai frames into the same javascript "domain" as the portal we decided to use Apache JkMounts.

• Note that Apache 2.2 using mod_rewrite has more flexibility than previous versions of Apache using mod_jk in mapping AJP connectors into the server namespace.

Webservices Modifications

• Loadbalancer issues introduced by webservices
• Authentication Verification Callback
• uPortal Session Synchronization
• One-call webservices
  • webservice calls between uPortal and Sakai must be load-balanced, because of the nature of the loadbalancer, you can't load balance calls between two servers on the same network interface on the loadbalancer. Due to availability of ports of the loadbalancer, all the hosts are on the same interface behind the loadbalancer.

All The Moving Parts:

1. The Sakai Portlet
   1. calls webservices for site list
   2. displays tabs [javascript/css]
   3. encrypts authentication token [crypto jars]
   4. paints sakai iframe
   5. passes authentication token
      1. by cookie
      2. by url parameter
2. The Authentication Servlet Filter (Sakai) 
   1. decrypts authentication token (passed by cookie or parameter) [crypto jars]
   2. calls back to uPortal registration servlet
3. Registration Servlet (uPortal) (optional?)
   1. verifies session is ok
   2. registers a HttpSessionBindingListener for callback [CallbackListener]
4. Sakai container login
   1. uses REMOTE USER set from Servlet Filter
   2. Sakai site is displayed in iFrame
5. uPortal-Sakai Logout synchronization (optional?)
   1. HttpSessionBindingListener calls Logout url on SakaiSession

 Modifications to uPortal Theme Stylesheet

Appendices

Appendix uPortal Configuration Details

uPortal: Apache Httpd and Tomcat

Each server is configured with one Apache httpd server (Apache-2.0.53?) in front of a tomcat container (tomcat-5.0.28?) connected by a local AJP 1.3 connector (mod_jk 1.2.17?).

The apache httpd's provide the SSL (via mod_ssl).  All the servers use the same cert so as to appear as one server when served out through the load balancer (https://myuva.virginia.edu).

We also make use of several Apache Modules (e.g. mod_pubcookie, mod_rewrite) to accomplish things that we could not have done with Tomcat alone. 

uPortal PubCookie Authentication

Authentication into MyUVa is implemented using PubCookie Authentication.   The mod_pubcookie (3.3.0a) Apache module is used in Apache httpd to provide the container authentication.   We also provide other password-based means of authentication into our uPortal (including even authentication against Sakai webservices).  The Sakai-uPortal authentication mechanism does not rely on PubCookie for authentication.

uPortal Load Balancing

MyUVa utilizes 3 webservers and one database server.  The webservers are load balanced using a hardware load balancer (Cisco LocalDirector).  Currently we are using  "SSL-ID sticky" session stickiness although we have encountered some potential bugs associated with doing so.  We are considering switching to a different session-stickiness mechanism.  [ lexplanation of session stickiness? ].  Round-robin session distribution is used, and we find that it yields the most even load-balancing in production, especially in light of the usage pattern of the portal.