This page is for capturing notes from the Sakai integration meeting in Chicago. 6-7 September 2005.
Who
- Steven Githens, Northwestern
- Dr. Chuck Severance, Sakai
- Vishal Goenka, SunGard SCT
- Eric Dalquist, Unicon
- Michael Ivanov, Unicon
- Peter Kharchenko, Unicon
- Andrew Petro, Yale
Integration steps
Sakai and uPortal 3 in Same Tomcat
Allows sharing service bean instances.
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).
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.
Sakai Tools as portlets configurable via the Portlet API
...
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.
- HTTP Basic authentication as a quick win that covers most of the need.
- 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.