-
Notifications
You must be signed in to change notification settings - Fork 3
EdpUser Concepts
The purpose of EdpUser is to provide a flexible foundation for the common practice of user authentication / identification and registration. Ultimately, a user will authenticate via some authentication adapter, and upon successful authentication will be identified by a populated user model for the given session. The focus of EdpUser is flexibility and more importantly, extendibility. EdpUser should be able to successfully serve as a starting point for authentication in a very large percentage of ZF2 web applications with widely varying names.
- EdpUser must provide a working solution for user registration and authentication (as well as the related activities such as forgot password, etc) out of the box.
- EdpUser must provide exemplary user password security and implement well known best practices.
- EdpUser must allow developers to easily override the default user model class.
- EdpUser must allow developers to easily extend the default user model class.
- EdpUser should support the usage of either Zend\Db or Doctrine2 out of the box.
- EdpUser must allow developers to easily swap the underlying persistence layer (mapper) without trouble.
This is a class that actually defines what a user is in your application. When referencing users in your code, you will always generally be working with instances of this object, regardless of how a user authenticated with your application.
EdpUser provides a nice and simple user entity by default which is compatible with both Doctrine2 and Zend\Db, however you may override this class and define your own user model. If your model does not conform to the provided user interface, then you'll need to make your own mapper (explained below).
The mapper is a class that conforms to a specific interface, which proxies access to the underlying data persistence mechanism. For example, two default mappers are provided by EdpUser: one for Zend\Db, and another for Doctrine2. The goal is that all interaction EdpUser makes with the persistence layer depends simply on this interface, which makes supporting additional data persistence layers for EdpUser very simple.
Authentication adapters are where EdpUser will really shine. The goal of EdpUser is to support a rich variety of authentication scenarios.
This is what EdpUser provides out of the box. Users are simply authenticated against a database which is accessible via Zend\Db or Doctrine2. Authentication consists of a successful combination of either e-mail + password or username + password (configurable by the developer implementing EdpUser).
Third party authentication is becoming more and more popular. EdpUser should allow for authentication workflows where users may be authenticated by redirecting the user's browser to a third party site then validating a token once they return.
For the sake of consistency, such third party authentication adapter modules should still result in EdpUser obtaining a populated instance of the user model class upon successful authentication. Third party authentication should be able to be used for registration and/or authentication in any way desired by those implementing it.
I have started on two modules which should eventually work to provide such third-party authentication (neither is functional yet as of writing this):
- EdpUserSocial - A multi-provider social authentication adapter for EdpUser which includes support for most common sites like Google, Facebook, Twitter, Yahoo, AOL, etc. Uses the HybridAuth PHP library.
- EdpGithub - Meant to be a generic module for GitHub integration for ZF2 sites using GitHub's v3 API, but will also contain the adapter(s) needed to integrate with EdpUser's authentication system.
EdpUser should also allow for third party modules which provide existing standard toolkits and best practices such as:
- Mozilla BrowserID
- Various Federated Login techniques
- Google Identity Toolkit
- Account Chooser
EdpUser should allow for authentication adapters which provide Two-Factor Authentication. A well-known example of this is Google's two-step authentication. Once this is possible, a free SMS-based two-phase authentication adapter will be made available for developers to use. I will issue special SMS Cloud API keys to those who wish to use this that will be able to be used for sending authentication codes to users free of charge.
In the following two examples, standard database authentication would be used in conjunction with an additional two-factor authentication module which supplements the standard authentication.
Scenario 2, Example 0: (BankOfAmerica.com) User enters username and continues onto next page. If the user has two-factor authentication enabled, an authentication code is generated and sent to the user via SMS. Once the user receives the SMS with the authentication code, they enter the code on the page and continue. If the code matches, the user is presented with the third and final step where they enter their password to complete the authentication process. Note that this is a bad example, as a malicious users needs only the username of a victim to bombard them with authentication code messages.
And...
Scenario 2, Example 1: (Google.com) User enters username and password and continues to next page. If the user has two-factor authentication enabled, an authentication code is generated and sent to the user via SMS. Once the user receives the SMS with the authentication code, they enter the code on the page and continue. If the code matches, the user is successfully authenticated.
Another interesting authentication strategy employed by Google is the concept of application-specific passwords. This allows for generating long, secure, random passwords which can be stored for use in applications which authenticate a user against a service. It would be cool if EdpUser were flexible enough the another module could provide a feature like this.
Going along with scenario 3, it would be cool if EdpUser could be used as the backend for a website which is an OpenID and/or OAuth provider for other applications.