Sakai 2 integration issues

Owned by Former user (Deleted)
Last updated: Jun 25, 2009Version comment
3 min read

The Sakai 2 kernel provides three institutional integration points:

  • Authentication
  • User directory and profile
  • Groups and roles

Each allows only one external source provider, and so any federation has to be handled within that provider service.

Sakai 3 must support the integration requirements met by Sakai 2 and also address Sakai 2's most pressing open issues, the greatest number of which appear to relate to groups and roles.

1. Authentication

Sakai 2 Issues

1.1. Integrated authentication is mature enough that customized builds should no longer be needed by most institutions. Instead, Sakai should support out-of-the-box configuration for the most common integration choices, using well-supported industry-standard libraries (such as Apache Ki, Jasig CAS, or Spring Security) to implement them.

2. User directory and profile

Project coordination problems led to Sakai 2's user directory handling being split between kernel services (with a minimal set of properties) and a profile component (including EduPerson properties).

Sakai 2 Issues

2.1. Context-sensitive flexibility when resolving user record properties is required by several important use cases:

  • Some users within a workspace should view different values from other users. EXAMPLE: Inside a course site, an instructor might be able to see a student's ID number, whereas students or a visitor would not.
  • Some workspace types should display different values from other workspace types. EXAMPLE: an official student number might be necessary in an official course site, but intrusive in a project workspace or social space.
  • Some values should be customizable by workspace. EXAMPLE: An instructor uses different email addresses for each course. EXAMPLE: In a role-play exercise, an instructor wants students to be identified by their roles rather than by their real names.

3. Groups and roles

Because course structures are central to an LMS, Sakai 2 includes one out-of-the-box group/role provider which connects to the Course Management API. Unfortunately, project coordination problems blocked full delivery of a coherent experience to developers, administrators, or end users.

Sakai 2 Issues

3.1. Groups are functionally scoped by site. Some use cases would benefit by easy access to installation-wide group hierarchies, defined apart from any particular workspace. Others call for groups which occur only in a subarea of a workspace.

3.2. Sakai 2 includes two types of group: "legacy groups" (which tended to be managed in an "ad hoc" fashion) and "sections" (which tend to be drawn from course management data). Despite their functional overlap, the two are implemented and managed separately. This results in many UX and adminstrative discrepancies and in greater development and QA overhead.

3.3. Because the CM-based group-and-role provider is the default, some applications and services incorrectly assume that it and a CM API implementation will always be available and useful. Currently, at least, that's not the case: less classroom-oriented or less hierarchically-driven deployments may well take a different approach to group-and-role integration.

3.4. In out-of-the-box Sakai, it's effectively impossible to know when changes in the external source data will be reflected in the corresponding site memberships. (The question appears on the sakai-dev mailing list many times every year.) Merge controls need to be made more transparent.

3.5. When multiple external groups and roles feed site memberships, it's possible for a single user to be provided by conflicting authorities (e.g., one source says Jim is "Staff" and another source says Jim is "Student"). Overlapping sources need to be dealt with more transparently.

3.6. Sakai 2's "realm template" approach to authorization makes installation-wide changes to roles or permissions expensive, and interferes with several common administrative needs. See the Federated Authorization page for examples.

3.7. The Sakai 2 Course Management API was developed because no existing standard interface met a wide range of shared LMS integration needs. However, IMS is expected to target the same use cases with a Learning Information Services specification well within the Sakai 3 development timeframe. If at all possible, integration in Sakai 3 should be based on the new standard (with contributed extensions as needed).