-
Notifications
You must be signed in to change notification settings - Fork 343
ZfcUser Concepts and Goals
The purpose of ZfcUser 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 ZfcUser is flexibility and more importantly, extendibility. ZfcUser 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.
- ZfcUser 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.
- ZfcUser must provide exemplary user password security and implement well known best practices.
- ZfcUser must allow developers to easily override the default user model class.
- ZfcUser must allow developers to easily extend the default user model class.
- ZfcUser should support the usage of either Zend\Db or Doctrine2 out of the box.
- ZfcUser 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.
ZfcUser 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 ZfcUser: one for Zend\Db, and another for Doctrine2. The goal is that all interaction ZfcUser makes with the persistence layer depends simply on this interface, which makes supporting additional data persistence layers for ZfcUser very simple.
Authentication adapters are where ZfcUser will really shine. The goal of ZfcUser is to support a rich variety of authentication scenarios.
This is what ZfcUser 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 ZfcUser).
Third party authentication is becoming more and more popular. ZfcUser 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 ZfcUser 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 ZfcUser 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 ZfcUser's authentication system.
ZfcUser 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
ZfcUser 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.
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.
Scenario 2, Example 2: (Google.com) Unauthenticated user is presented simply with a QR code they scan on their smart phone. This takes them to a page where they may complete authentication (enter credentials or authorize access) in a trusted environment, on their mobile device. Once authentication is completed on the device, the computer's browser is redirected and the user is successfully authenticated. Google calls this "Google Sesame". This helps mitigate the risk of hardware and software key loggers on the computer being used in situations where the environment cannot be fully trusted.
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 ZfcUser were flexible enough the another module could provide a feature like this.
Going along with scenario 3, it would be cool if ZfcUser could be used as the backend for a website which is an OpenID and/or OAuth provider for other applications.