OpenID is an increasingly popular universal sign-on mechanism on the web. Google, Facebook, LiveJournal, even Sears' online store are supporting it. We can, in theory, adapt Columbia logins to be an OpenID provider. This would allow members of the Columbia community to login to other sites which accept OpenID with their Columbia UNIs.

At Columbia, CUIT provides a single sign-on mechanism for services within the university called Wind , which is based on the more ubiquitous CAS .

One problem with depending on Columbia-only authentication/authorization is that it makes it awkward, if not impossible, for students or faculty to work together with non-Columbia affiliates in the same protected environments. Guest lecturers can't access the course materials. Researchers have difficulty collaborating across institutions.

The solution is to use a broader authentication method. Shibboleth is one that has been baking for a long time within the academic world, but it seems like OpenID provides many similar features and will allow our community to interface on more popular websites, too.

It's not available yet; we still need to talk to the folks at CUIT about why it's a good idea. However, I've written an implementation that should make the following scenario possible:

For any service on the Internet, you should be able to type into an OpenID login 'columbia.edu.' This will shepherd you to a Wind login, and then Columbia will authenticate you with the site. No saved passwords and, if you choose, your name and email will automatically be sent to them.

The system, as implemented, would also let you login as an anonymous Columbia student or faculty member. Sometimes you don't want a site to know your name or even be able to match your login with other sites you've logged in to the same way. Note, however, that the Columbia IT department could figure out who you are--you'd be trusting their servers after all.

Some tech details:
I used the mostly friendly JanRain php-openid library
OpenID is pretty complicated, and it took a bit of time before I started thinking my confusion was related to a bug in the code, rather than my confusion with the spec. Overall, though, the example server was a great place to start.

One gotcha I encountered toward the end of the implementation: I was getting an error when testing at openidenabled.com "OpenID authentication failed: No matching endpoint found after discovering [my OpenID]." It turned out that the Relying Party (the server for which you login), on the last step, queries the user's identity_url to check that it trusts the Provider (the server providing the login). When I checked what my provider was doing, it was serving the wrong information in that case--easily broken, but easily fixed with some better htaccess rules.

All the code is at http://github.com/ccnmtl/openid-wind-bridge