Home > DrProject, Teaching > Experiences with OpenID?

Experiences with OpenID?

December 27th, 2006

As regular readers will know, one of the features I like most in DrProject (and its predecessor, Trac) is the RSS feed it automatically creates showing events from each project.  Unfortunately, we’ve had to disable the feeds for class projects at U of T, since we don’t want students in one group to be able to see the check-in comments or ticket updates of another, and web-based blog reading services like Bloglines haven’t standardized on an authentication mechanism.

However, I’ve been seeing a lot of buzz about OpenID recently, which has me wondering whether it’s worth rolling the dice and incorporating support for it into DrProject.  Oh, and running some sort of authentication server in the department, tied into the IDs students are automatically allocated for courses.  I don’t want to venture into these waters without a guide — anyone out there done this yet?

DrProject, Teaching

  1. Igor
    December 27th, 2006 at 12:52 | #1

    Having HTTP authentication, or whatever it is that is currently up for RSS feeds is perfectly fine, it works very nicely and I can authenticate to a feed with my usual DrProject user name and password. The problem is that there is no “real” SSL certificate for stanley and so 95% of the RSS readers out there will refuse to let you authenticate to it. I think the only one I’ve seen that doesn’t refuse is Google Reader, but that happens to not be my reader of choice.

    I think getting a real SSL certificate will be both much more useful and much easier than developing an OpenID authentication module. (Not to discredit OpenID in any way, I’ve heard a lot about it and I think it’s agreat idea with great potential, I just don’t think it solves the right problem here).

  2. December 27th, 2006 at 15:38 | #2

    I made a screencast explaining OpenID from a user’s perspective recently: http://simonwillison.net/2006/openid-screencast/

    It doesn’t try to solve the RSS feed authentication problem – you still need to use cookies (or similar) to keep a user logged in once you have authenticated them against their OpenID.

    It would be a really nice thing to have in Dr Project though. The thing OpenID excels at is lightweight account management. You could create a new project and assign “ownership” permissions to a list of OpenIDs, without even asking your students to create an account with Dr Project itself (provided you already knew their OpenIDs, which could be based on their university accounts or accounts from external providers).

  3. flaps
    January 2nd, 2007 at 15:58 | #3

    Igor, thank you for your care in putting “real” in quotation marks. However, I would like in this message to use the term “real” for my own SSL certificate for stanley.cs.toronto.edu (“self-signed”, if you like), and “fake” (note the quotation marks) for the kind of certificate signed by organizations such as Thawte/Verisign and their bastard brethren.

    I would like to suggest that my “real” certificate is _better_ than a “fake” certificate. Here’s why:

    1) I am, personally, more trustworthy than Thawte and their bastard brethren. I could bring several arguments to bear here, but the one I think I’ll focus on is that I am doing this as a regular job, only, and not as an attempt to perpetrate some sort of entrepreneurial semi-scam. I am, for example, not going to attempt to parlay my control over the stanley.cs.toronto.edu certificate into additional revenue for other business ventures (like the event described in http://www.icann.org/topics/wildcard-history.html ).

    2) My certificate is better than Thawte and their bastard brethren’s root certificates. This is because my certificate only allows me to tell you that a certain web server is stanley.cs.toronto.edu (footnote), whereas “root certificates” allow the issuing agency to tell you that anything is anything. It is a security error to trust that organization that much, if at all avoidable. It is even a security error to trust _me_ that much. You should not, ideally, install any such certificates in your web browser.

    But of course I have the standard root certificates in my web browser, and so do you. And all this is secondary to your desire to access stanley.cs.toronto.edu through the rss reader and/or web browser of your choice. But let’s fix the latter issue directly, if possible, rather than paying “protection money” to Thawte.

    My web browser has not only the ability to “accept temporarily for this session” a self-signed certificate, and not only the ability to install it permanently when visiting the site for the first time and it asks; but also the ability to import a certificate from a file (and to remove certificates already installed, including those it “comes with”).

    I think I’ve put the public half of the certificate for stanley.cs.toronto.edu at http://stanley.cs.toronto.edu/certinfo/stanley.crt
    I’m actually still learning about SSL, but I think that this is what you need to install. (If you want to remove it, you’ll find it under “University of Toronto”.) Similarly, http://stanley.cs.toronto.edu/certinfo/drproject.crt
    (The easiest way to save them into a file might be to start at http://stanley.cs.toronto.edu/certinfo/ and then say “save this link into a file” instead of clicking on it)

    If your RSS reader doesn’t seem to be willing to import certificates, please e-mail me its name and distribution web site, and I’ll look into it. I bet it can import the certificate, one way or another, as I think that large ssl-using software authors realize that they’re risking anti-monopoly court cases if they recognize only the authority of Thawte and their bastard brethren.

    (footnote) Actually, with only a little investigation so far, I’m not certain that this is correct. If it isn’t, it _should_ be; that is, there ought to be a way for me to give you a file to install which allows me to certify stanley.cs.toronto.edu ONLY, and allows you to see that that’s all it does. For example, when I do financial transactions on my bank’s web site, it really is a security error that I’m trusting verisign to authenticate the bank rather than the bank itself. There should be a certificate they hand me on a floppy disk when I get my bank card (this card is required for web banking already), and to access web banking via SSL I should have to put this floppy in my computer and double-click on it. The vast majority of computer users these days can double-click on things, although both Microsoft and Apple seem to be trying to make their software useable even by those who can’t. But they haven’t managed to dumb the users down _quite_ that much yet.

  4. flaps
    January 5th, 2007 at 18:32 | #4

    Despite the above, I’ve now obtained zero-cost SSL certificates from ipsca.com and they’re installed…

Comments are closed.