can't login to ikiwiki.info (perl's Net-OpenID-Consumer?)

The perl code debugging tells me there is something missing from the association:

[Sun May 15 15:32:11 2011] [error] [client 192.168.0.3] [DEBUG Net::OpenID::Consumer] handle_assoc: dumb mode: no_handle, referer: http://anarcat.ath.cx/hamwiki/ikiwiki.cgi?page=Main_Page&do=edit

thanks for that... unfortunately, the openid_provider.module doesn't have such debugging, which makes things quite hard to figure out...

The issue here is the Relying Party (RP) isn't able to store the association key for some reason (seems to be a limitation in Ikiwiki), so it falls back to some dumber mode:

# return a handle for an identity server, or undef if
# no local storage/cache is available, in which case the caller
# goes into dumb consumer mode.  will do a POST and allocate
# a new assoc_handle if none is found, or has expired

The OpenID 2.0 standard states that:

openid.assoc_handle
  Value: (optional) A handle for an association between the Relying Party and the OP that SHOULD be used to sign the response.

  Note: If no association handle is sent, the transaction will take place in Stateless Mode.

Stateless mode is:

11.4.2.  Verifying Directly with the OpenID Provider

To have the signature verification performed by the OP, the Relying Party sends a direct request to the OP. To verify the signature, the OP uses a private association that was generated when it issued the positive assertion.

https://openid.net/specs/openid-authentication-2_0.html#check_auth

So it seems like this is part of the standard that isn't supported... ?

Indeed, openid_provider_verification_response() mentions it supports

// 9.2.2.2. Verifying Directly with the Identity Provider

, but then goes around checking in its tables to see if the association handle is present, which seems to be a mistake - it should just validate the signature it received.

This could be related to that long-lasting feature request: #506530: Private association support. Or it's just a problem with client malformed data (e.g. #831162: cannot login on stackoverflow or dotnetopenid sites).

I do not have duplicate query string elements as in #831162: cannot login on stackoverflow or dotnetopenid sites though, so my problem is elsewhere (most notably: no assoc_handle is sent from the RP). According to the spec the transaction is supposed to take place in stateless mode, but doesn't explain clearly how this is supposed to happen.

I am running with this patch in production, but I am worried it is incorrect, especially due to this part of the spec:

For verifying signatures an OP MUST only use private associations and MUST NOT use associations that have shared keys. If the verification request contains a handle for a shared association, it means the Relying Party no longer knows the shared secret, or an entity other than the RP (e.g. an attacker) has established this association with the OP.

However, maybe a private association is exactly what we're doing here... we're creating a new 'nonce' that is known to the OP and delievered to the RP.

The problem is that it seems that generating nonces like this all the time is not necessarily a good idea:

http://lists.openid.net/pipermail/openid-general/2009-April/017584.html

... as it can lead to a DOS attack on the provider.

I have nevertheless produced a patch that fix authentication on ikiwiki sites, and probably others that do not have their own storage of openid data. I would appreciate feedback regarding the above issues.

This has been working fine in production for a while, committed.

So it seems I broke this recently. Now I can't login to ikiwiki.info anymore.

phew! fixed this again, now for good i think. this one was really hairy. see commits b7a1c8a68711674748de422d2a7a58cba42e5673 and 3aa74dda367d7e15e0379f13db2cf74f001b1d35 for more information.

For the record, this is how to enable openid debugging in ikiwiki:

--- /usr/share/perl5/IkiWiki/Plugin/openid.pm.orig      2012-01-29 23:45:45.707281457 -0500
+++ /usr/share/perl5/IkiWiki/Plugin/openid.pm   2012-01-29 19:00:07.883446184 -0500
@@ -258,6 +258,7 @@
                args => $q,
                consumer_secret => sub { return shift()+$secret },
                required_root => $cgiurl,
+               debug => 1,
        );
 }