1 Using Sakai in Stellar at MIT Mark J. Norton, Nolaria Consulting Craig Counterman, MIT Mark Brown, MIT

2 The MIT Course Management System is called Stellar designed and built by Craig Counterman. The project was started in 2001 to provide on-line support for existing MIT classes. Quickly grew to support basic support needs: homework, schedule, forums, etc.

3 Background and History 2001: Stellar project started to provide on-line support for MIT classes. 2002: OKI objects added. 2004: MIT is a founding partner of the Sakai project. 2005: Explored adding Sakai tools. 2006: Stellar and Sakai integrated.

4 Statistics There are 509 classes on Stellar for Spring 2006 (so far) Stellar class websites have been created since Of all Stellar class websites 49.7 % are graduate courses and 50.3 % are undergraduate courses.

5 Original Stellar Architecture Plug-in tool capability: –Stand alone tools –Integrated tools Core objects were based on the emerging OKI OSID specifications. Several presentation technologies are supported. A diagram shows it better….

6 Stellar 1 Architecture

7 Stellar Tools Materials Homework and drop box Schedule and Announcements Sign up for Sections Discussion forum based on Jive Syllabus Etc.

8 New Tool Development New tools are easy to build in Stellar. The new ImageTool, for example. However, MIT wants to take advantage of the large number of tools being developed for Sakai. A replacement for Jive was needed.

9 Stellar Home Page

10 Some Problems Sakai has it’s own portal – Charon. Maintains it’s own user sessions. Runtime includes –Component management. –Tool state and placements. –Preferences, etc. Tools use Sakai’s authorization system.

11 Solution! Create a null portal that: –Accepts requests for Sakai tools –Maintains the Sakai user session –Creates or finds tool placement as needed –Manage other environment concerns This is called LaunchPortal in Stellar. Leads to a new architecture….

12 Stellar 2 Architecture

13 Request Processing In stellar, a URL is of the form: nexus/nexus/nexus/tool/tool-arguments Each request is processed to find a tool. Proxy tools are added to forward a request to the LaunchPortal. The LaunchPortal then forwards it to the appropriate Sakai tool along with a context. Tools return HTML.

14 Request and Response Flow Stellar Tool Proxy Launch Sakai Tool Aggregator RequestResponse HTML Content Aggregated Content

15 Preserving the Sakai Session Stellar uses a regular java.servlet session and a servlet session cookie for state. This is the JSESSIONID cookie. Stellar was already using this, so code had to be added to preserve Sakai session information and forward it to the request handler This is done via a HttpServletRequestWrapper in the proxy tool which eliminates the non-Sakai cookie from the request.

16 The Launch Portal LaunchPortal is a null portal built by stripping down Mercury to it’s essentials. It still has a very limited UI, but is intended to run without a UI by forwarding requests to appropriate Sakai tools based on incoming tool id.

17 LaunchPortal public class LaunchPortal extends HttpServlet { public String getServletInfo() public void init(ServletConfig config) throws ServletException protected void doGet(HttpServletRequest req, HttpServletResponse res) protected void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException protected void doError(HttpServletRequest req, HttpServletResponse res, Session session) throws IOException protected void doHome(HttpServletRequest req, HttpServletResponse res, Session session) protected void doTool(HttpServletRequest req, HttpServletResponse res, Session session, String toolId, String context, String toolContextPath, String toolPathInfo) throws IOException protected void forwardTool(ActiveTool tool, HttpServletRequest req, HttpServletResponse res, Placement p, String toolContextPath, String toolPathInfo) protected void showSession(PrintWriter out, boolean html) private void initSession (HttpServletRequest req, HttpServletResponse res, Session session, String context) }

18 Request Processing The doGet() method is the usual entry point to the LaunchPortal since most are HTTP GET requests. doPost() replicates most of doGet() just in case a POST request is needed.

19 1. Logic in doGet() User name is passed in on an attribute. Largely manages paths and URLs. If there is no session, one is created for this user. This happens in initSession(). Checks for development UI case or, Calls doTool(). Context also passed via an attribute.

20 2. Logic in doTool() Gets the Sakai tool associated with the tool id passed. Uses the context to find or create a tool placement, a combination of a tool and a context (usually a site or section). Calls forwardTool().

21 3. Logic in forwardTool() Makes sure that attributes are set for the HTML head and style sheet references. Uses the forward() method in the Sakai tool to forward the request to the tool being invoked.

22 Error Handling Since LaunchPortal is a real servlet, any errors encountered while preparing to launch or transfer to a Sakai tool can be wrapped into an HTML error page. Exception information is logged in catalina.out

23 Content Aggregation Sakai tools are generally written to appear in an iFrame. Stellar avoids the use of iFrames for accessibility and graphic design reasons. HTML content from Sakai tools will be aggregated via an XML transform. TBD

24 JForum in Stellar

25 Sakai Tool Integration In order for Sakai tools to work fully in the Stellar environment, they must be integrated with user and group data. Sakai includes three providers for integration to enterprise data services: –UserDirectoryProviderImplemented –GroupProviderExtended –CourseManagementProviderUnused

26 User Integration StellarUserProvider fully implements the UserDirectoryProvider against Stellar user data using a OkapiUser object. User data is currently limited to: –First and Last Name – address –(but more data could be added)

27 Authorization Sakai provides limited support for authorization integration using the GroupProvider API. This provider gives access to group names, membership, and group roles. It does NOT allow authorization grants to be resolved externally.

28 Extensions to GroupProvider Since Stellar sites are not defined as groups in Sakai, access can’t be determined locally by the Security Service. In order to properly determine authorization requests by Sakai tools against Stellar users and groups, the Group Provider was extended with three methods: –isAllowed() –isGroup() –getAllowedFunctions()

29 Three New Methods Boolean isAllowed (userId, ftn, realm); Boolean isGroup (groupId); Set getAllowedFunctions(role, groups); More methods than these may be needed to fully support external authorization. These were the minimal ones needed to make Message Center and Jforum work.

30 GroupProvider Implementation The StellarGroupProvider is implemented against Stellar Nexus data that contains sites, roster lists, and user roles. This is done directly against Nexus objects, thus avoiding database interaction.

31 Tool Lessons Learned Sakai tools can be made to work in non- Sakai UI environments using an intermediary to maintain a Sakai session. Some hand-off support is needed to ensure tool ids, context, and arguments. The environment is more flexible than some might think!

32 Integration Lessons Learned Authorization is at the heart of integration. User and Group info is easy, but authorization can be hard. The Sakai providers are good, but can be improved for greater flexibility.

33 Future Work External authorization may be better done by re-implementing AuthZGroups rather than via the GroupProvider. Course Management and Sectioning providers will be needed to allow any Sakai tool to run in Stellar.