OpenID for DokuWiki
What it is about is not much really. If you never heard about OpenID I recommend the Screencast by Simon Willison as a first introduction.
OpenID is a simple distributed identity system, though identity does not mean verified identity here. It's just a small convenience. Instead of creating a free user account on all the sites you need to register for doing stuff (editing a wiki, posting in a forum, adding a comment in a blog) you can automatically login there with your OpenID. It's not about any trust or additional security - you can create a fake OpenID as simple as registering a fake account on the site it self.
But convenience is good, isn't it? So what about having OpenID logins in DokuWiki? I went through a few OpenID PHP libraries, but they seemed overly complicated for what I had in mind. I didn't need any OpenID server components, I just wanted to login through it. So as usual I wrote my own. The specifications are open but not as simple as they could be in my opinion. Especially the flow of data wasn't 100% clear to me at first.
But finally I understood and just released the first version of the OpenID plugin for DokuWiki. I implemented a very simple OpenID consumer1) within an action plugin. In hope to make it easier for others to implement similar functionality I will outline its workings here.
- The action plugin adds a link to the OpenID login form to the usual login form (basic stuff)
- The user follows the link submits the OpenID login form with his ID
- Now the user is redirected3) to this provider where a number of things can happen:
- The user may be asked to login at her OpenID provider (once per browser session)
- The user may be asked if she really wants to login at the referring site
- The user may be asked if she want to send certain other data back to the refering site (email, nickname, timezone …)
- The user can add the referring site to her “trusted” sites to autologin the next time
- If user is already logged in and has added the site to his trusted sites, no user interaction is required at all here
- After any user action is done on the provider's site, the provider redirects the user back to where she came from, with additional data and a cryptographic hash of this data
- We're now back in the wiki plugin
- Because the redirect could be faked we need to ask the server again (in background) if the provided data and the hash are valid4)
- If the background check returns true we have a valid login
- To make the wiki believe we have a real logged in user we set up the auth cookie and the auth session variables accordingly
The above is the simplest method of implementing an OpenID consumer (called dumb mode) there are different ways which rely on some cryptography in the consumer itself. In dumb mode all cryptography is done on provider side.
So the whole thing works, but I haven't installed it at wiki.splitbrain.org, yet. This is because I'm still thinking about the implications this could have. What would be very convenient for users could prove much more convenient for spammers. I'm not the only one who asks this and Simon Willison's answer seems to suggest that I should distrust OpenId users a little bit more than usual users…