Archive for the 'elgg' Category

OpenAcademic goes live!

Sunday, July 30th, 2006

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 in an Educational Context

Thursday, July 27th, 2006

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.