I'd like to see moin act as an OpenID server.

Use cases [most are fictional]:

  1. JohannesBerg would like to have http://johannes.sipsolutions.net/ as his OpenID and not allow anyone else to use that wiki for their OpenID even though user registration for email notifications is allowed. He sets page_front_page to JohannesBerg. His wiki is not editable by anyone but himself.

  2. BenjaminBerg would like to have http://benjamin.sipsolutions.net/ as his OpenID and not allow anyone else to use that wiki for their OpenID even though user registration for email notifications is allowed. He doesn't want to set page_front_page to BenjaminBerg though. His wiki is not editable by anyone but himself.

  3. The MoinMoin wiki should serve OpenIDs for the MoinMoin developers but not anyone who signs up to the wiki.

  4. Debian's wiki is editable by DDs only and wants to allow them to use the wiki for OpenIDs.

  5. Gnome's wiki is editable by anyone and wants to allow anyone to use the wiki for OpenIDs, but people may only use http://wiki.gnome.org/UserName.

The easiest way to implement OpenID server support is probably going to be an action combined with an optional processing instruction.

Default case

If the OpenID server is enabled, moin will serve 

<link rel="openid.server" href="http://johannes.sipsolutions.net/?action=serveopenid"/>
<link rel="openid2.provider" href="http://johannes.sipsolutions.net/?action=serveopenid"/>
<meta http-equiv="x-xrds-location" content="http://johannes.sipsolutions.net/?action=serveopenid&amp;yadis=ep">

in the <head> section of user homepages. If the openid_server_restricted_users_group configuration option is used, this is limited to the listed usernames.

This already covers all the use cases but Benjamin's.

Processing instruction

To cover Benjamin's use case, a new processing instruction is introduced:

#OpenIDUser BenjaminBerg. When this instruction is used, moin will also generate the html head contents as in the default case, but the action looks up the contents of the OpenID processing instruction instead of using the page name as the username. Note that this form of the processing instruction can never override the default.

Configuration

For the use cases where not everyone may use the built-in OpenID server, the use can be restricted by the following configuration options:

  1. openid_server_enabled (boolean): used to enable/disable the built-in OpenID server completely

  2. openid_server_enable_user (boolean): If set, the OpenIDUser processing instruction is allowed.

  3. openid_server_enable_delegation (boolean): If set, users can delegate their OpenID by entering the relevant information into their user profile.

  4. openid_server_restricted_users_group (page name): if set, the page it points to contains a list of usernames that are allowed to use the wiki as an OpenID server.

Possible further configuration options:

  1. openid_server_provider_list (list, or page name with a contained list?): list of external providers allowed with openid_enable_external_providers

  2. ...?

Action

The action does the actual authentication work, it checks whether identity-URL's page name is a valid username and contained in the openid_server_restricted_users_group if applicable. If not, the processing instruction is checked (according to the configuration of course).

code

Currently doesn't implement delegation.

Patch can be found at in http://johannes.sipsolutions.net/patches/moin/all/ under the name openid-server2.patch, but other patches in the series may be required.

to do

MoinMoin: JohannesBerg/OpenID support/server (last edited 2007-10-29 19:10:48 by localhost)