Tag Archives: integration

Hybrid: State of the Union

It has been a while since I have written about the Sakai Hybrid integration between CLE and OAE. With some visioning help from David Goodrum and some technical wizardry by Steve Githens, we managed to hit a major milestone leading up to the Sakai 2011 Conference. This milestone allowed us to perform a live demonstration of a couple of important use cases:

  1. Using the Sakai OAE portal to launch directly into a CLE site experience.
  2. Being able to pull individual CLE tools into OAE content pages as widgets.

The first use case is important if you want a single URL for your users to enter their LMS experience regardless of whether they are primarily CLE or OAE users. This mode will allow CLE users to ease into an OAE experience while maintaining a very familiar CLE user interface.  In other words, think of it as a new portal for CLE that has some new capabilities.

The second use case is targeted more at users who are adopting the complete OAE user experience, but still need access to some functionality provided by the CLE (think of Assignments, Gradebook, and Tests & Quizzes as examples). This capability allows one to pull one or more CLE tools into an OAE content page as widgets. The other interesting thing is that the underlying technology behind this tool integration is what is known as IMS Learning Tools Interoperability or LTI for short.  This technology will not only allow OAE to pull in external CLE tools, it will also allow OAE to pull in other LTI enabled tools or applications (think EtherPad, WordPress, Moodle, or Blackboard as examples).

David Goodrum introduces the Hybrid concept and value proposition:

Lance Speelmon demonstrates Hybrid use cases:

Steve Githens expands on possibilities:

Finally we wrap up with some Q&A:


1 Comment

Filed under Education, Sakai, Technology

Sakai 3 Basic LTI… Now with more policies!

In an upcoming screencast, I will demonstrate a new Sakai 3 widget that hides all of the complexities of LTI settings from the end user. In the previous demonstration [1] you were able to see individual Sakai 2 tools living side-by-side with Sakai 3 widgets. You also saw a “sleight of hand” where I tried to paste in a 1) LTI URL, 2) LTI key, and 3) LTI shared secret without you noticing. While this made for decent “demo-ware”, it was an unreasonable set of expectations for a user who say simply wants to place a Sakai 2 Assignments tool onto a Sakai 3 page. My goal was to allow users to be able to place a Sakai 2 tool onto the page without having to know any settings.

To reach this next level of simplification, the required LTI settings would need to be supplied via administrative policies. Luckily, when I started developing the LTI service in Sakai 3, I anticipated such a need and built in some preliminary support for policies. Let’s start by taking a look at a policy, sakai.assignments.grades:

    "ltiKeys": {

All of the Basic LTI widget settings can be configured via such a policy. There are two aspects to each setting, 1) the setting itself and 2) a lock. The interaction between the two works as follows:

  1. If no setting is configured, the Basic LTI widget will not be affected in any way.
  2. If a setting is supplied (i.e. with no lock) it will become a default value for the setting in the widget.
  3. If both the setting and the corresponding lock are set, then it becomes a policy which the end user cannot change.

Hopefully this is fairly straightforward. However, we have not talked about the key to a policy itself. That is to ask, what causes an associated policy to be read and applied during the launch of the Basic LTI widget? It is another setting on the widget itself: lti_virtual_tool_id. For example, setting lti_virtual_tool_id to a value of sakai.assignments.grades would cause the policy named /var/basiclti/sakai.assignments.grades to be applied. This will allow system implementers to create many virtual tools and policies for end users, either because they want to simplify their lives with some good default values, or they need to lock some of the settings down so that end users cannot modify them. Now before you get too excited, the bad news is that while all of this logic exists and has been tested in the backend service itself, it has not been added to the Basic LTI widget yet. You will be able to see these policies in action in an upcoming blog posting where I will demonstrate a new widget called “Sakai 2 Tools”. This new widget essentially has no settings as relies completely on the new administrative policies.

While we are on the subject of policies, there is another new feature in the Basic LTI service worth mentioning. This is a little abstract, but essentially LTI has a property context_id which has meaning similar to what Sakai might call a siteId. The Sakai 3 LTI service now has the ability to manually specify the context_id if needed. This will be important to the Sakai 2/3 Hybrid integration as we will want Sakai 3 to pass the siteId of the corresponding Sakai 2 site as the context_id. Let me explain in more detail:

  1. The Sakai 2 LTI provider normally operates in the following provisioning manner:
    1. If the user does not exist, create it.
    2. If the site (i.e. context_id) does not exist, create it.
    3. If the tool placement does not exist, create it.
  2. This is all well and good if you are integrating some untrusted third party system where you want all of the LTI stuff to be completely separate from your local stuff.
  3. But if you are integrating with something closer to home (i.e. more trusted), then you probably don’t want all of this provisioning occurring.
  4. For a given LTI key, the Sakai 2 LTI provider can be placed into a trusted mode where it will not perform any account, site, or tool provisioning.

It is this trusted mode of the Sakai 2 LTI provider that we are targeting with the ability to manually specify the LTI context_id in Sakai 3. To invoke this new capability, simply set the property lti_context_id on the Sakai 3 site node to the siteId of the Sakai 2 site. As you can see from the DefaultContextIdResolver, the value of lti_context_id will be used if it exists, otherwise, the fully path to the site node will be used as the context_id.

  public String resolveContextId(final Node node) throws RepositoryException {
    LOG.debug("resolveContextId(Node {})", node);
    if (node == null) {
      throw new IllegalArgumentException("Node cannot be null");

    String contextId = null;
    if (node.hasProperty(key)) {
      // we have a special context_id we can use
      contextId = node.getProperty(key).getString();
    } else {
      // just use the path
      contextId = node.getPath();
    return contextId;

Until next time… L

[1] https://lancespeelmon.wordpress.com/2010/04/27/mix-and-match-sakai-2-and-sakai-3-tools/

Leave a comment

Filed under Sakai, Technology

X-SAKAI-TOKEN Authentication

I would like to draw your attention to some important changes in plumbing that is used in the hybrid integration between Sakai 2 and Sakai 3. First a little background… Previously, an authentication mechanism existed that allowed a system external to Sakai 2 to call into its services while not prompting the user for authentication and trusting the external system for the user’s identity. This has been used primarily to allow services in Sakai 3 to call services in Sakai 2 to retrieve, for example, lists of sites for which the user is a member. This kind of authentication should not be confused with a single-sign-on solution like CAS which casts the end user as the primary actor. This type of authentication mechanism is used for server-to-server communication, on behalf of the user, and is established by system administrators who declare trust relationships between the two systems. The basic flow looked like:

  1. End user requests data from Sakai 3 via HTTP GET method (e.g. to get a set of Sakai 2 sites for the current user).
  2. Request is proxied through Sakai 3.
  3. Sakai 3 adds a header to the request: X-SAKAI-TOKEN (includes username).
  4. Sakai 2 receives the request and examines the X-SAKAI-TOKEN.
  5. If the token is valid, establish a new session based on the username passed in the token, and process the request.

So let’s examine this a little closer… An example X-SAKAI-TOKEN looks like:


The token is comprised of three pieces of information separated by semicolons:

  1. EEFSxb/coHvGM+69RhmfAlXJ9J0= : A cryptographically secure hash of the message.
  2. admin : the username of the current user signed into the calling system, i.e. Sakai 3 in this example.
  3. 1273688664630 : Number of milliseconds since the epoch.

Inquiring minds are probably wondering why Sakai 2 would trust such a token… I mean, just because a web request shows up at your front door and has some official looking identification, does not mean we should allow them to run code as admin, right? Well that is where the next concept is introduced: the shared secret. Think of a shared secret as a password that both systems know. Sakai 3 used the shared secret to sign the message and since Sakai 2 also has the shared secret, it can verify the integrity of the message (i.e. ensuring the message has not been spoofed or tampered with in any way). Just to be clear, the message admin;1273688664630 is signed using the shared secret to create the hash EEFSxb/coHvGM+69RhmfAlXJ9J0= and then the hash is prepended to the message to create the token X-SAKAI-TOKEN: EEFSxb/coHvGM+69RhmfAlXJ9J0=;admin;1273688664630. Now Sakai 2 has everything it needs to verify the token. It can use it’s own shared secret to compute a hash of the message and verify it equals the hash that was passed in the token. If the hashes are equal, the message is valid and has not been tampered with in any way.

This capability is great for calling into Sakai 2. But lately I have started looking into how tools or widgets might start passing results between systems. Think about a student submitting an assignment to a Sakai 2 tool and having the results posted to a Gradebook running in Sakai 3.  We needed a way for Sakai 2 to be able to call into Sakai 3 using the X-SAKAI-TOKEN mechanism — and now we have it! Thanks to some help from Dr. Ian Boston, we have pulled the same authentication and identification techniques into Sakai 3; with some improvements of course:

  1. The HTTP header X-SAKAI-TOKEN has been renamed x-sakai-token (to save on your CAPS LOCK key).
  2. The signature has been upgraded to the latest and greatest standards: RFC 2104 compliant HMAC (Hash-based Message Authentication Code). Thanks to Carl Hall for adding this capability to Sakai 3.
  3. sakai.auth.trusted.server.enabled: setting to completely enable or disable this feature.
  4. sakai.auth.trusted.server.safe-hosts: setting to control which other servers we trust.
  5. The Sakai 2 implementation has also been updated with the same great improvements.

So now that we have some plumbing installed, I will return to considering results passing between Sakai 2 and Sakai 3. 🙂

PS – This same mechanism could be used with 3rd party systems if desired. Build a message, sign it with an HMAC, and stuff it into an HTTP x-sakai-token header and away you go… Think about it…


Filed under Java, Sakai, Technology

It’s Official: Sakai 3 has passed IMS Global’s LTI Certification

SakaiIMS Basic LTI Enabled

Just this week IMS made the official LTI certification test suite available and I am very pleased to announce that Sakai 3 has passed the certification tests with flying colors (i.e. 100%). Now we can display this cool “Basic LTI Enabled” image with our software. As of this writing, this distinction is shared only with Desire2Learn. You can keep up-to-date on the progress of LTI certifications by watching: Common Cartridge and Basic Learning Tools Interoperability Progress.

While the Sakai 3 LTI consumer has the potential to bring interesting 3rd party tools into the learning management system, our primary motivator for this work was to provide a way to surface Sakai 2 tools within Sakai 3. Using LTI to solve this problem has positioned us well and we are anxious to see other developers implement the LTI provider server-side interface. Thanks to Dr. Chuck, Sakai 2.7 will ship with both an LTI consumer and LTI provider!

For more information on Basic LTI, see: Basic Learning Tools Interoperability. If you are interested in the certification test suite, see: Sakai 3 Basic LTI Widget Passing Certification Tests.


Filed under Education, Sakai, Technology

Mix and match Sakai 2 and Sakai 3 tools

I am very pleased to be able to share an important update with the Sakai community regarding the ongoing efforts to create a flexible migration path from Sakai 2 to Sakai 3. I have been blogging recently [1] [2] about the development of a new Basic LTI widget for Sakai 3. This effort builds on the existing capabilities [3] of Sakai 3 which allows you to expose entire Sakai 2 sites within the Sakai 3 portal (i.e. with the addition of Sakai 3’s social networking features). The next step in this hybrid evolution was to add the capability to expose individual Sakai 2 tools within Sakai 3 sites. Furthermore, since we were developing this new capability as a Sakai 3 widget, this means that an end user could place multiple Sakai 2 tools onto a single Sakai 3 page (i.e. something not currently possible in Sakai 2). This may sound like a subtle distinction, but as you will see in the embedded video it is an important distinction as it helps to break Sakai 2 tools out of their silos. Instructors can now author pages with custom workflows that may include both Sakai 2 tools and Sakai 3 widgets!

Skip to 12:30 into the video if you want to skip the summary and background…

So now we are beginning to see a migration path for existing Sakai 2 implementations that looks like:

  1. Sakai 2 for course sites and Sakai 3 for project sites.
    1. Reduced risk deployment as there is no hard dependency on Sakai 3 being available. For example, if Sakai 3 were to go down, users could easily be directed back to the Sakai 2 portal.
    2. Sakai 3 portal may or may not be the default portal (i.e. implementers choice).
  2. Placement of Sakai 2 tools alongside Sakai 3 pages within a Sakai 3 site.
    1. Maintains more of a Sakai 2 user experience while allowing access to Sakai 3 capabilities within a single site.
    2. Provides a nice transition between #1 and #3 for those that find it valuable.
    3. Increases risk as now users are dependent on Sakai 3 remaining available.
  3. Mixing and matching Sakai 2 and Sakai 3 tools all on the same Sakai 3 page within a Sakai 3 site.
    1. Provides the greatest flexibility for course and project site design.
    2. Provides the most “native” Sakai 3 user experience while maintaining access to Sakai 2 functionality.
    3. Custom workflows may be created with both Sakai 2 tools and Sakai 3 widgets (i.e. even if you are just exposing Sakai 2 tools, this capability does not exist in Sakai 2).
    4. Maintains same risk profile as #2.
  4. Implementer’s selection…
    1. You do not need to think of the previous three deployment strategies as mutually exclusive or synchronous.
    2. You can make any or all of these solutions available to select user populations as you see fit at any time – all based on your local goals and comfort levels.

For example, one possible migration path may look like:

  1. Build confidence in Sakai 3 and keep risk at a minimal levels.
    1. Deploy Sakai 3 alongside Sakai 2 with hybrid mode enabled.
    2. Continue to use Sakai 2 for course sites.
    3. Begin to experiment with Sakai 3 portal and project sites.
    4. Make Sakai 3 portal available to select user populations to validate access to Sakai 3 social networking capabilities as well as access to Sakai 2 sites.
    5. Make Sakai 3 project sites available to select user populations.
  2. Make Sakai 3 portal the default portal for all users.
    1. Continue to use Sakai 2 for course sites.
    2. Expand use of Sakai 3 project sites.
    3. Develop fallback plan to mitigate dependency on Sakai 3 portal availability (i.e. you still have a fully functional Sakai 2 portal sitting there).
  3. Early adopters begin relying on Sakai 3 for course work.
  4. Full adoption of Sakai 3 for both course related and collaborative work.

There is a lot to consider here and to complicate matters further I predict not one migration will be identical to another. However, we hope that we have provided enough capabilities and flexibility to tailor each migration to fit the institution’s needs. Furthermore, there is a lot experience in our community in this area as almost all of us have made a similar migration in the past. This time things are a little different… This time we have direct control over both systems and can make the migration smoother.

Let’s continue the discussion in person at the annual conference. Christian Vuerings and I will be presenting on this topic in sessions titled “Integrating Sakai 2 and Sakai 3”. There will be two regular conference sessions and a technical demonstration. See you there! L

[1] http://bit.ly/9Brbdl
[2] http://bit.ly/bXVPVI
[3] http://bit.ly/bQKjlm


Filed under Education, Sakai, Technology

Sakai 2->3 Integration Status Update

David Goodrum asked me to provide an update to the Oncourse Priorities Committee [1] regarding the progress made towards Sakai 2->3 integration and migration. In doing so, it became clear that this kind of update might also be useful to the community at large. There are two overarching goals to achieve in this project: 1) seamlessly exposing Sakai 2 functionality within Sakai 3 (which we are dubbing “hybrid” mode) and 2) content migration.

The hybrid mode will allow institutions to adopt Sakai 3 at a pace that is comfortable for them. For example, Sakai 3 will not have all of the functionality available in Sakai 2 day one, but their will be some compelling functionality that institutions will want to adopt before all of the functionality gaps have been closed. Hybrid mode will facilitate this approach by allowing institutions to deploy Sakai 3 and take advantage of the new features while still relying on Sakai 2 for the features not yet available in Sakai 3. The following video demonstrates the first step in realizing hybrid mode: the ability to expose entire Sakai2 sites within the Sakai 3 portal.

We anticipate that institutions will want to start using Sakai 3 for full-fledged project and committee work before course work. This capability supports this use as Sakai 3 sites can be used for project sites while Sakai 2 continues to serve the course site needs. The next step in the hybrid mode evolution will be the ability to place individual Sakai 2 tools onto Sakai 3 pages which live in Sakai 3 sites. This will give the user the ability to mix and match both Sakai 2 and Sakai 3 functionality in a single user experience.

Next: content migration. The primary use case that we are tackling first is the ability of an instructor who taught a class last semester in Sakai 2 to be able to import that site template into Sakai 3. The following video demonstrates an initial deliverable where one can export content from a Sakai 2 site and then import that content into a Sakai 3 site. Please keep in mind that this is very early work and is rough around the edges, but the methodology and underlying service is sound.

Moving forward, focus in the following areas is required:

  1. Exposing individual Sakai 2 tools on Sakai 3 pages within Sakai 3 sites.
  2. Exploring a results mechanism so that a tool hosted in Sakai 2 can report results to a tool hosted in Sakai 3 (and vice-versa). As an example, you might want to use a Sakai 3 Assignments tool which will need to report outcomes to a Sakai 2 Gradebook.
  3. Continued effort to import Sakai 2 site templates into Sakai 3 for semester-to-semester transitions.
  4. Deeper content migration that will not only transfer site templates, but also include full user content. For example, this will likely be a requirement to migrate a project site from Sakai 2->3.


Filed under Sakai

Sakai 2+3 Hybrid Status Update

I am happy to provide you with a status update on the progress that has been made since the previous post: Sakai 2+3 Hybrid pre-alpha. I think you will be most pleased with the outcomes and in many ways provides a better user experience than what is available in the Sakai 2 portal! The speed at which you can switch between tools is quite amazing. Check it out:

Many thanks to: Ian Boston, Paul Bristow, Oszkar Nagy, Christian Vuerings.

1 Comment

Filed under Sakai