Download & Extend
OpenID Provider » Issues

Private association support

Posted by Aron Novak on June 30, 2009 at 7:05pm
Project:OpenID Provider
Version:6.x-1.x-dev
Component:Code
Category:task
Priority:critical
Assigned:Unassigned
Status:fixed

Issue Summary

For implementin update_url in AX modules (openid_client_ax and openid_provider_ax, take a look on #501702: Support update_url AX method to update profile data and #501704: Support update_url AX method to update profile data)
http://openid.net/specs/openid-authentication-2_0.html , openid RP needs to send an unsolicited positive assertion what needs to be signed with the help of a private association.
As I see there is no direct support for doing such assertations and signs.

Login or register to post comments

Comments

#1

Posted by anarcat on May 15, 2011 at 9:33pm

I looked at this problem in the course of fixing #1158356: can't login to ikiwiki.info (perl's Net-OpenID-Consumer?), and it's hairy. The spec, basically, is unclear: it never explains exactly what *is* a private association.

Can you clarify exactly what's required here?

#2

Posted by anarcat on January 30, 2012 at 4:43am
Status:active» needs work

Even though I am not quite sure what is needed here, we have done one small step in this direction: we are able to record private associations during check_setup, and that code has been factored in a separate function in commit b7a1c8a68711674748de422d2a7a58cba42e5673. there is a openid_provider_unsolicited_assertion() function that is totally unused right now, but I suspect could be used to implement this.

I would really need to understand what we're talking about though. :P

#3

Posted by anarcat on January 31, 2012 at 5:09pm
Priority:normal» critical

Alright, I think I figured this out. This is simply a verification check (check_authentication), that is done using private keys (which are recorded in check_setup). The thing is, the spec (https://openid.net/specs/openid-authentication-2_0.html#verifying_signat...) says:

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.

So we do verify associations, but we do *NOT* verify only private associations... we gladly take any association, including shared associations built up earlier. That's not good. I have added todos for this in the code and an attempt at an implementation, in 6.x.

#4

Posted by anarcat on February 1, 2012 at 12:27am
Status:needs work» fixed

This is now fixed in git. I think this implementation is now complete.