Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

This page is for capturing notes from the Sakai integration meeting in Chicago. 6-7 September 2005.

Who

  • Steven Githens, Northwestern
  • Chuck Severance, Sakai
  • Vishal Goenka, SunGard SCT
  • Eric Dalquist, Unicon
  • Michael Ivanov, Unicon
  • Peter Kharchenko, Unicon
  • Andrew Petro, Yale

Integration steps

(See also entry on Chuck's blog).

Sakai and uPortal 3 in Same Tomcat

Set up uPortal deployment so as to eliminate jar conflicts where both Sakai and uPortal deploy the same jars. Make the connection so that uPortal code can "find" Sakai components, APIs, etc. Ultimately allow Spring injections of Sakai components in uPortal Spring configurations.

GAPs and uP3 delivers API-only .jars

Provides integration APIs for Sakai to provide implementations of without Sakai having to import all of uPortal and all its .jar depdenenceies, etc.

uPortal-backed Sakai User Directory Provider implementation

A Sakai user directory provider implementation that's backed by uPortal. Allows a Sakai intance to delegate to uPortal for user attribute, directory provisioning. Potentially for shared username, password in Sakai, uPortal w/o using CAS or another SSO server.

Sakai tab injected into render pipeline

A uP3 render pipeline plugin / hack to replace a particularly named or identified tab (folder) in the layout with a (configurably deep) fragment of layout containing Sakai IFrames.

Sakai tool portlets

First and simplest, just configured instances of the IFrame Portlet. More ambitious, JSR-168 that leverages Vishal's WSRP production work to grab tool content (not using WSRP, but similar approach using direct cross-context dispatching and the portlet.request).

This provides something more interesting to have as the "leaves" of the tree of the injected Sakai tab. It also allows traditional layout management with layouts containing Sakai content.

Sakai tool placements (tools in the context of sites) available from Sakai via the GAPs abstraction (get a group of portlets).

Allows making portlets fronting Sakai tools-in-context available for subscription individually / incluson in layouts.

A Sakai GAP Group Store implementation vending groups of Sakai portlets.

Sakai groups available as GAPs groups

A Sakai GAP Group Store implementation vending groups of Sakai users. This should be done in a nice hierarchical fashion Sakai->Sites->Pages->Tools using the hierarchy available in the GAPS and Channel Subscribe.

Sakai Tools as portlets configurable via the Portlet API

In this situation, we make a virtual portlet for each Sakai tool. WHen a user adds the tool to the layout, it notices that tit does not have a configured pre-existing Sakai placement ID. So it uses the WindowID to create a new placement in Sakai. The key tricky bit here is getting AuthZ to work. This will be done by using the roles available to the portlet - the Portlet will ask if the user is in the "admin" role and for the context of the placement, use that role to pick a realm which confers a set of permissions. This will require some changes to the Sakai framework.

WSRP

Securing Sakai WSRP

Need to secure Sakai WSRP production to at least authenticate the WSRP consumer communicating with it. Should update uPortal WSRP consumer apace with the WSRP producer (make it able to authenticate in the way Sakai comes to require).

  • Sakai filter to assert that request presents localhost / expected IP address as remote address – Completed 10/21/05
  • HTTP Basic authentication as a quick win that covers most of the need – Completed 10/21/05
  • HTTPS Client SSL certificate authentication as a possibility.
  • WS-Security Username, Token profile
    • Could present a traditional username, password pair that Sakai could authenticate as if a login
    • Could present a username, CAS proxy ticket pair.
    • How the "password" is validated should be easily replacable Sakai side; not the hard part.
  • SAML using WS-Security SAML profile. Has nice features as an eventual solution, not realistic near them.

We decided that the highest priority was to do the address filtering, followed by Basic Authentication, followed by WS-Security profiles - we need to look into getting Axis to do the heavy Authorization lifting.

Outstanding Issues

  • Getting the CSS pulled up from the fragments to the top page - can be done ad hoc for a while
  • Delivery of events - may want to hold off until uPortal does some XMLHttpRequest stuff - some of the AJAX ideas.

Go forward plans

Andrew will start working in earnest on the tasks soon and Chuck will help as well.

  • No labels