| | 1 | [[PageOutline]] |
| | 2 | Original author: Benoit Grégoire, last modified: 2007-03-01 |
| | 3 | = Why OpenID = |
| | 4 | Supporting OpenID would be a very good thing. There are PHP libraries available so it wouldn't be too hard to implement, and Wifidog is exactly the type of software it was meant for. |
| | 5 | |
| | 6 | However OpenID is a very misunderstood specification. What OpenID basically does (and all it does) is provide a mechanism to prove that one (or more) person owns a URL. It also allows two independent systems on the Internet to know that two users with the same OpenID are indeed the same user (or group of users) |
| | 7 | |
| | 8 | == Single sign-on == |
| | 9 | OpenID's main benefit is single sign on. In fact, it works almost exactly like the way the wifidog gateway currently authenticates a user against the auth server. And for the user, not having to remember (and give us...) yet another password for wifidog is something that will make many people very happy. |
| | 10 | |
| | 11 | == Wifidog federation == |
| | 12 | OpenID is not, however, a distributed trust model. It is also not, in and of itself, a way for two systems to share a common userspace. So it does not make it as much easier for us to do federation as one may think. |
| | 13 | |
| | 14 | We can't simply say: "Trust any open id at (for example) the http://auth.nycwireless.net identity provider". It would work, but would defeat the main purpose of OpenID by forcing every user doing roaming to sign in using the URL of a specific IdP. |
| | 15 | |
| | 16 | We could however use OpenID as the backend to exchange credentials. Somebody selects NYC wireless from a popup (can't skip that step unlike the above), and types in his username only (which may be his OpenID, but doesn't have to be). Wifidog can then custom-build an OpenID query (which is not the way OpenID usually works) to be sent to the NYC wireless auth server using the OpenId protocol. The user logs-in there (or is possibly further delegated to another OpenId server), and then get's back to the original auth server, logged-in. That's very secure for the user (less so for the group). But it should work, even if that's not really what OpenID was designed for. |
| | 17 | |
| | 18 | = Implementation = |
| | 19 | There are off course several thorny UI questions to answer. |
| | 20 | |
| | 21 | On the backend implementation side, there are three almost independent features to build: |
| | 22 | * Allow wifidog to act as an OpenID consumer, and allow the user to convert an existing account, or sign up a new account using OpenId. |
| | 23 | * Allow wifidog to act as an OpenID server (identity provider), and make it delegate if the user is already using OpenId. |
| | 24 | * Allow wifidog to use a remote auth server's identity provider as an authenticator for a Network (it does depend on #147: network peering to work, but that's trivial). |
| | 25 | |
| | 26 | So I think that using OpenID for single sign on is VERY desireable. Using it for federation is an option among others to consider. |
