Using Sakai in Stellar at MIT

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. 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. Background and History

4. There are 509 classes on Stellar for Spring 2006 (so far). 2729 Stellar class websites have been created since 2001. Of all Stellar class websites 49.7 % are graduate courses and 50.3 % are undergraduate courses. http://stellar.mit.edu Statistics

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

6. Stellar 1 Architecture

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

8. 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. New Tool Development

9. Stellar Home Page

10. 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. Some Problems

11. 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. Solution! Leads to a new architecture….

12. Stellar 2 Architecture

13. 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. Request Processing

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

15. 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. Preserving the Sakai Session

16. 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. The Launch Portal

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. 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. Request Processing

19. 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. 1. Logic in doGet()

20. 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(). 2. Logic in doTool()

21. 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. 3. Logic in forwardTool()

22. 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 Error Handling

23. 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 Content Aggregation

24. JForum in Stellar

25. 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: UserDirectoryProvider Implemented GroupProvider Extended CourseManagementProvider Unused Sakai Tool Integration

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

27. 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. Authorization

28. 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() Extensions to GroupProvider

29. Boolean isAllowed (userId, ftn, realm); Boolean isGroup (groupId); Set getAllowedFunctions(role, groups); Three New Methods 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. 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. GroupProvider Implementation

31. 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! Tool Lessons Learned

32. 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. Integration Lessons Learned

33. 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. Future Work