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).

• 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

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

Request Response

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

LaunchPortalpublic 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:– UserDirectoryProvider Implemented– GroupProvider Extended– 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– Email 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.