Description

When Moin is set up as an OpenID identity provider, and when another Moin instance is trying to authenticate using that provider as one of the "allowed" providers (using the openidrp_allowed_op configuration setting), authentication always fails with the message Server denied check_authentication when the browser is redirected to the relying party (the Moin instance requesting authentication).

Steps to reproduce

1. Configure one Moin instance to act as a provider using the openid_server_enabled setting.

2. Configure another Moin instance to act as a relying party, making sure that the openidrp_allowed_op setting has at least one provider defined, obviously including the URL of the first Moin instance's front page.

3. Visit the login page of the relying party instance, after making sure you are logged out, and attempt to log in by choosing the provider defined above.
4. Select your identity in the interface of the provider Moin instance (perhaps needing to log in first).
5. Upon redirection to the relying party Moin instance, the above error will appear.

Component selection

• MoinMoin.action.serveopenid

Details

Workaround

Don't use the allowed providers list.

Discussion

The bug is caused by the provider Moin instance returning an endpoint which is different to the URL that the relying party discovers. This confuses the underlying python-openid library which then tries to check the authentication using a different means, but this fails because although the provider Moin instance has an OpenID association stored, it is of the wrong kind for the check_authentication method.

Here's the underlying workflow involved:

1. The relying party (RP) establishes an association which is stored in "smart" mode in the identity provider (server) and tied to a particular endpoint in the consumer.

2. The RP sends a checkid_setup request and ultimately gets a response involving the same association handle but a different endpoint from the server.

3. The RP now attempts to verify the association but fails - the endpoint is different - and then sends a check_authentication request to the server.

4. The server tries to look up an association based on the handle being used, but this fails because it is now in "dumb" mode.

Fortunately, I have a patch for 1.9.x and for 1.8.x (virtually identical to the first) which seems to fix this problem without apparently breaking the other OpenID authentication methods. It does this by invalidating any server-side (provider Moin instance) association where the endpoint has changed, thus anticipating that the relying party will dislike such behaviour.

Plan

• Priority:
• Assigned to:

• Status: applied patch, see http://hg.moinmo.in/moin/1.9/rev/4ab3c578e44b

CategoryMoinMoinBugFixed CategoryMoinMoinPatch