doc/todo/separate_authentication_from_authorization.mdwn

   1 [[plugins/openid]] and the new [[plugins/emailauth]] both assume that
   2 the user's authentication identity (how they log in) is suitable as
   3 an authorization identity (who they are when they have logged in). In
   4 particular, the OpenID or email address goes into the git history.
   5
   6 Relatedly, I'm not sure I'd be comfortable with enabling [[plugins/emailauth]]
   7 on my own sites while it writes users' email addresses into the git history:
   8 non-technical people (and many technical people for that matter) get
   9 possessive about who can know their email address. The usual expectation for
  10 email addresses on websites seems to be that they will be used by the site
  11 owner (and maybe their outsourced service providers), but not available
  12 to random third parties. The principle of least astonishment would suggest
  13 that we should do the same here.
  14
  15 > This part is now addressed by cloaking email addresses:
  16 > `smcv@debian.org` → `smcv@02f3eecb59311fc89970578832b63d57a071579e`
  17 > (that's the sha1sum of `mailto:smcv@debian.org`, as used in FOAF).
  18 > --[[smcv]]
  19
  20 (The expectation of privacy for direct git commits is rather different:
  21 I think we can expect direct git committers to know that they
  22 should either set a plausible non-email-address in their git identity,
  23 like I used to use my OpenID, or have good spam filtering.)
  24
  25 If we present email-based users in the "web UI" using only the local-part
  26 of their address, we also have a potentially confusing situation where
  27 `chris@example.com` and `chris@other.example.net` both contribute to a wiki:
  28 if I'm reading the code right, they'd both be presented as `chris`, with no
  29 way to change that other than using a different email address?
  30
  31 Here is a sketch of a different account model that would address that:
  32
  33 * An account has a username, e.g. `smcv`. It normally matches some regexp that
  34   includes neither @ nor / (to rule out collisions with email addresses
  35   and OpenIDs).
  36
  37   * We currently allow qr{-[:alnum:]+/.:_} by default, so passwordauth
  38     accounts can in principle collide with OpenIDs. That would probably be
  39     worth fixing (for new account creation) anyway - I don't think we want
  40     users with / in their names, which would make their user-page into a
  41     subpage?
  42
  43     > I have fixed passwordauth to not let urls be registered. It seems this
  44     > was not quite a security hole; it didn't let registering a username that
  45     > already existed, so if an openid was an admin, as long as the user logged
  46     > in using that openid, someone else couldn't come along and passwordauth
  47     > collide with it. (Might be exploitable if you could guess an openid that
  48     > was going to be added as an admin later though.) --[[Joey]]
  49
  50 * If passwordauth is enabled, accounts may have a password. Users can
  51   authenticate to an account that has a password by entering that password.
  52   The username is always the account name (because there's little reason
  53   to do anything else).
  54
  55 * If httpauth is enabled, anyone who can authenticate to the web server
  56   automatically gets access to the account of the same name in the wiki.
  57   (Or we could consider having a configurable map
  58   { web-server-level username => wiki account } but the default would be
  59   an identity mapping.)
  60
  61 * If OpenID is enabled, accounts may have an OpenID.
  62   The owner of that OpenID can log in, and gets logged-in to that account.
  63   Either reusing the same OpenID for multiple accounts is not allowed, or
  64   if the same OpenID is attached to more than one account the user can choose
  65   (as an extra step). Optionally, more than one OpenID could be allowed.
  66
  67 * If emailauth is enabled, accounts may have an email address.
  68   Users can authenticate to an account that has an email
  69   address (and is not a grandfathered OpenID) by using the token challenge.
  70   (passwordauth accounts could already do a password-reset, so this is not
  71   any less secure.)
  72
  73 * Creating an account from an email address (maybe also OpenID?) has a new
  74   step: choosing a username, with some text about "this name will appear
  75   in recentchanges and in the wiki's history". The default would be the
  76   local-part (user) from the email address.
  77
  78 * Grandfathered OpenID support: every existing account that looks like an
  79   OpenID has that OpenID associated with it, and it cannot be changed or
  80   removed. The displayed form is openiduser().
  81
  82 * Grandfathered emailauth support, if required (but it might not be required
  83   if we implement this model before the next ikiwiki release): every existing
  84   account that looks like an email address has that email address associated
  85   with it, and it cannot be changed or removed. The displayed form is
  86   emailuser() but we should maybe change that to output something more
  87   like `smcv@…`.
  88
  89 * Hypothetically, an account could also have a https client certificate
  90   for a new client-certificate plugin, or a Google account for a new OAuth2
  91   plugin, or whatever, and all of the above applies equally.
  92
  93 * Unlike the current OpenID support, if the user's authentication provider
  94   goes away (or if Google stops doing OAuth2 and moves on to the next big
  95   thing), they can associate a different authentication identity with
  96   their existing wiki account, and continue.
  97
  98 This is basically the same model that Mozilla Persona encourages,
  99 except using emailauth ourselves instead of outsourcing (the equivalent
 100 of) that step to Mozilla.
 101
 102 Thoughts?
 103
 104 --[[smcv]]
 105
 106 > I always find it a little ackward that i have two different accounts on this wiki: one for OpenID, and the other (regular account) for email notifications (because of [[bugs/notifyemail_fails_with_some_openid_providers/]]). It seems to me those accounts should just be merged as one, ie. I was expecting to be able to choose a username when i registered with openid.
 107 >
 108 > Also, when you talk about "separating authentication from authorization", i immediately thought of [[todo/ACL/]] and [[todo/Zoned_ikiwiki/]], so i thought i could mention those... having stability in the usernames would help in the design of those... --[[anarcat]]
 109
 110 > I'm not opposed to this, but I don't anticipate having resources to do any
 111 > work on it either. (I do hope to obscure email addresses from git
 112 > commits.) --[[Joey]]