Page MenuHomePhabricator

Extract email delivery from PHPAS
Closed, ResolvedPublic


Affects R1 and R?

This is a rather bittersweet ticket, PHPAS has always been proud to not disclose the email addresses of users to third parties. And while I don't want to change this in the near future, it's a design choice that has been in the way of PHPAS maturing as a micro-service.

PHPAS has always done Authentication AND Email delivery. The and needs to go. It represents that PHPAS is attemtpting to also be an email gateway, which it is not supposed to be. Instead it should receive a companion service that acts as a proper email gatevway and can perform all the tasks of sending and receiving email from a PHPAS based network, without becoming a bottleneck to the network.

There will always be a leftover intertwinement between identity and email. Because we use our email (and maybe our phone number) to log into systems. PHPAS should understand that a piece of contact information is also a mechanism for two-factor authentication. It should be able to offload email delivery to another service on the network, and this service must be able to find the email it has to send to.

So we need to allow certain applications to access contact information for users, so they can reach out to the user properly.

For this, the architecture of PHPAS needs to change. Every user should have several passports (I want to call them passports to prevent confusion with the identities provided by rPERM), contacts and 2FA methods.

  • A passport provides anidentity for log-in (usernames, email address, phone) - it needs to be unique and should be able to be canonicalized
  • A 2FA provides two factor authentication mechanism (email address, phone, RSA token, 2FA codes, security questions)
  • A contact provides a way to contact the user (email address, phone)

These must be able to be linked together, allowing the user to opt into removing all of the associated authentication mechanisms at once. For example, when a user registers using, the email is used as a passport to log in, a contact to send notifications to, and a 2FA mechanism for retrieving lost passwords/authenticating tokens. All of these options must be linked together, so if the user wishes to remove their old email, the system recognizes the change and replaces all three, instead of just one.

Event Timeline

cesar triaged this task as High priority.Apr 16 2020, 6:31 PM
cesar created this task.
cesar created this object with visibility "Public (No Login Required)".

Relay and rPERM are now proper independent applications that can be managed externally - this task is therefore no longer necessary