Over the last few months, I’ve received a few emails about how to get involved in the project. Toward that end, we set up a Mediawiki instance at http://wiki.openacademic.org. The wiki is pretty barren now, but we will be fleshing it out with more details on our roadmap, and our ideas all steps of the development process.

Since we brought the site live, one of the challenges we have faced is balancing the time necessary to do the work with the time necessary to let people know about the work. It’s an ongoing challenge, and we hope the wiki will help alleviate some of that inherent tension.

We are looking for people who want to get involved — people who are using these tools in the classroom, and developers who are writing code that supports a focused integration between these tools, and folks who are just plain interested. If you match any of those definitions, or even if you don’t, come on down.

And, it is OpenID enabled.

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 , with the install tested by Kevin and us.

The code is available here:

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.

In an earlier blog post, Sean Lancaster asked the following question:

i appreciate the effort that is being undertaken to create a terrific online learning environment that brings various resources together seamlessly; however, i am curious to better understand how Drupal and Moodle are different in what they provide. i mean, why would a person use both tools at the same time?

The short answer is that the best option is a subjective determination — kind of like Mac vs PC, etc, etc.

A slightly longer answer is that the choice of tool for the learning environment will be determined by the relationship between learners’ needs, instructors’ needs, and institutional needs.

A still longer answer is that making an across the board choice is no longer necessary, and we are at a place where it’s possible to match the tool to teaching/learning style. It’s possible for an institution to provide these tools side by side to support learners and teachers in the classroom.

Moving outside the classroom, Drupal is a pretty flexible tool that can be used to create intranets for different academic departments, club sites, a public facing school site, an alumni forum — and within each of these contexts, Drupal can be customized and focused to meet the specific needs of the site users. Some people have also used Moodle to meet these needs. The need for a “one size fits all” approach no longer exists, as we have options.

All of these elements (and others ) will factor into the decision. It’s possible to set up OpenAcademic without Drupal, or without Moodle. The solution is, by design, flexible and scalable. However, it’s necessary to stress that the choice of tool to use is just that: a choice. The user has options. The institution has options. The sysadmin has options. People and institutions do similar things in different ways. The work we’re doing at OpenAcademic is intended to provide a flexible, adaptable toolkit. Using the tools within OpenAcademic, you can create a simple web presence, or a learning network that connects learners and institutions on different sides of the world. You can choose to use the tools — in any combination — to meet your needs in your way.

If you’re still awake and reading at this point, I’ve written more about ideas related to this topic here and here and here.

At long last, we are happy to announce the launch of the OpenAcademic project. This project is dedicated to integrating Elgg, Drupal, Moodle, and Mediawiki. All code developed under this project will be released back to the respective communities under an open source license, and it will be freely available to download and distribute.

Yeah. We’re silly like that.

This project arose from a series of online discussions about Elgg, Drupal, and Moodle, and how these tools fit in an educational setting. As we continued to talk about these tools, we all saw the opportunity to create a better online learning environment — a learning space that incorporated informal learning alongside a more formal course structure, and that drew from the strength of the community-building software already built by the open source community.

Over the next few days and weeks, we will be talking more about our plans and vision for the integration. In general terms, the integration will start with single sign on between sites, and the ability to move content seamlessly between sites. The integration will also include the ability to search across sites, and to aggregate tags across sites. As the integration develops, these tools have the potential to create a truly distributed network of learners.

This integration, and this site, are very much works in progress. As I mentioned above, we will be writing about our precise vision for the initial integration. As we develop code, we plan to release it as early and as often as possible. We want people to use it, and to give us feedback, and to get involved in the process. Towards that end, we will be launching a developer site shortly — a site where developers can find information on how to get involved, meet other coders working on the project, and share code back. Look to this space for an announcement about when the developer site goes live. In the meantime, if you want to help out with the code, or talk to us about development for your institution, don’t hesitate to contact us.

Currently, the project is moving forward on a few fronts. We have been focusing on single sign on, as we see that as a central piece of functionality. Work is underway on building out Elgg as the front end for an OpenID server, and Moodle integration of OpenID has also begun. Drupal is also OpenID enabled, and there is an OpenID plugin in the Mediawiki svn repository. We have also looked at a few possibilities for searching across multiple sites, and for aggregating tags across sites. One of the items on Elgg’s long term roadmap is the ability to search user profiles and maintain friends across different Elgg installs, and some initial work on that has also been completed.

So, here’s to the beginning of something fun.

Cheers,

The OpenAcademic team

OpenID provides a method of Single Sign On (SSO) between multiple web sites. OpenID allows users to “claim” a specific url; this url identifies the user as they browse and join different web sites.

Other SSO options exist, including Shibboleth, , Pubcookie, and JA-SIG’s Central Authentication Service. OpenID differs from other methods in a few ways, but the purpose of this post is not to compare or contrast the pros and cons of the different SSO options. This post is also intended as an overview to demonstrate some possibilities, not as the final word on what OpenID can or can’t do.

Far too frequently, conversations that set out to compare and contrast different standards end up denigrating one standard in order to elevate another. This type of conversation seems counterproductive; as with any technological solution, the best solution will be dictated by the specific needs of the institution or organization. While OpenID will not be the perfect choice for every situation, it combines flexibility, security, simplicity, and scalability. These traits make OpenID an attractive choice in a wide range of scenarios.

Background:

Two things are required to use OpenID: an OpenID server, and an OpenID-enabled client site. The OpenID server is the site where users claim their unique url. An OpenID url looks exactly like a web address; for example, if an OpenID server is set up at elgg.net, a user’s OpenID url would be http://elgg.net/username — more to come on this later. Then, using their unique url, the user can log into any site that is set up to accept OpenIDs. Among open source projects, . There are also to simplify the process of OpenID-enabling other applications.

to OpenID providers (to get your own OpenID) and downloadable OpenID servers (to set up your own server). Within an organization you can set up one OpenID server that serves as the central authority for managing SSO to selected resources. OpenID servers can also be incorporated into existing applications, so that any site member also receives an OpenID. For example, an OpenID server can be incorporated into Elgg, which creates some interesting possibilities — more to come on this later.

It is also important to note that OpenID is both an open standard, and that many of the applications that use OpenID are released under open source licenses.

OpenID is also gaining traction among larger companies. an OpenID implementation with their .

OpenID Features:

Single Sign On (SSO): OpenID allows for SSO between sites that are OpenID enabled.

User management: an OpenID server can authenticate against a wide variety of data sources, from a .pwd file to user data in a legacy system via LDAP. So, an OpenID server does not require an institution to maintain and synchronize multiple sets of user data. OpenID servers have been set up to allow pluggable authentication against a broad range of data sources to allow for maximum flexibility.

Whitelist/Blacklist sites: OpenID client sites can be configured to whitelist and blacklist sites. To demonstrate how this works, consider the following scenario:

Johnny is a sixth grader at Neighborhood Middle School, where they have an OpenID server. Using his OpenID, Johnny logs into his class web site, the chess club web site, and his personal learning space. Because all these sites are OpenID enabled, he only logs in once to do work in these different areas. However, because these are all different sites, Johnny can be a student within the class site, and a content moderator in the chess club site.

Within this same school, all client sites have been configured to only accept logins from the school’s OpenID users. So, any logins with an OpenID from outside the school community will be rejected. As with all other security systems, a user needs to have a valid username and password.

The whitelisting and blacklisting feature can also be used to support safe, secure online collaboration between different schools. If the Neighborhood Middle School developed a relationship with the Far Away Middle School, the two schools could set up a web site to allow logins only from each school’s individual OpenID server. So, members of the two school communities could have access to the site, and the rest of the internet would have no access.

Elgg as an OpenID server: Using Elgg as the front end for the OpenID server creates additional benefits. Elgg’s user profiles allow for flexible display of profile information, as the OpenID url points directly back to a user’s profile. For example, my Elgg profile is visible at http://elgg.net/bfitzgerald. If elgg.net was enabled as an OpenID server, my OpenID url would be the same as my Elgg profile. The long term roadmap for Elgg will allow for searching across different Elgg sites. The combination of whitelisted logins between different OpenID servers, searching across Elgg sites, and OpenID urls that point directly to a user’s profile will simplify collaboration between and across organizations.

Taking this a step further, OpenID could also simplify the process of allowing students from different schools to take the same class in a single Moodle install. If Moodle was OpenID enabled, it would be possible to whitelist OpenID servers from multiple schools. This has the potential to create a truly distributed learning environment: students from different institutions interacting in a more formal class structure (Moodle), and in an informal learning space (Elgg).

Where things stand now:

is actively working to OpenID enable Elgg as an OpenID server and client. are OpenID enabled, and we are creating an admin screen to simplify whitelisting/blacklisting sites. A Mediawiki extension is under active development in the Mediawiki subversion repository. There is also some preliminary interest in OpenID enabling Moodle, with at least one developer expressing an interest in writing the code to make this happen.