Current Status

3 min read

I've been wanting to find the time to write this post for a while, but different things (aka work, life) kept getting in the way.

For those who are interested in getting started in putting the different pieces of OpenAcademic together, here are some of the building blocks.

A Moodle 1.6 OpenID consumer:

This code was written by Kevin Jardine, with the install tested by Kevin and us.

The code is available here: http://code.google.com/p/oamoodleopenid/

We have not tested this code in a shared hosting environment, but we have tested it in a few different LAMP stacks. For those of you who are comfortable working in a Linux environment, the install is pretty straightforward. The one main obstacle we encountered was with miscompiled gmp libraries, and we documented the fix for this in the ReadMe.txt that comes with the download. For the generally curious, you can find out more about gmp here.

A Mediawiki OpenID consumer:

This code was written by Evan Prodromou, with some patches by Jonathan Daugherty. IE, these guys did all the work, and deserve all the credit :)

The code, and a description, is available here: http://www.mediawiki.org/wiki/Extension:OpenID

This install was also pretty straightforward, and, on our servers, also required that we recompile the gmp libraries. The readme for the Mediawiki code contains excellent instructions.

Educational Use:

There are a few nice things about these OpenID consumers, but my favorite feature is the trust routes. Both consumers allow the site admin to set domains that are fully trusted, partially trusted, and completely blocked.

A member authenticating from a fully trusted domain gains access without needing to verify an email address. A member of a partially trusted domain can gain access, but, the first time they join the site they need to verify some basic information. Subsequent logins are then streamlined. And, at the risk of stating the obvious, people attempting to gain access from blocked domains will never be able to gain access.

In an educational context, this means that an organization can set up an incrementally walled garden. People from selected schools can be granted access to specific shared resources (and denied access to others). People from other organizations can be granted access to selected resources, but only after their credentials are checked and verified. And, uninvited guests won't be able to gain access. In this context, OpenID provides the means to open up a learning environment between schools without requiring multiple passwords, and without opening the entire system to the entire internet. When combining the flexibility of OpenID with the flexible access control of different applications, one has a broad range of options for supporting online collaboration while protecting student privacy. An organization can set these tools up to be as open or as closed as they prefer.

Next steps:

Now, I just wish I knew some bryght folks who were working on a Drupal-based OpenID server and consumer. That would be very nice indeed.

, ,