-
Notifications
You must be signed in to change notification settings - Fork 2
LmcUser Concepts and Goals
The purpose of LmcUser 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 LmcUser is flexibility and more importantly, extendibility. LmcUser 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.
- LmcUser 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.
- LmcUser must provide exemplary user password security and implement well known best practices.
- LmcUser must allow developers to easily override the default user model class.
- LmcUser must allow developers to easily extend the default user model class.
- LmcUser should support the usage of either Zend\Db or Doctrine2 out of the box.
- LmcUser 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.
LmcUser 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 LmcUser: one for Zend\Db, and another for Doctrine2. The goal is that all interaction LmcUser makes with the persistence layer depends simply on this interface, which makes supporting additional data persistence layers for LmcUser very simple.
Authentication adapters are where LmcUser will really shine. The goal of LmcUser is to support a rich variety of authentication scenarios.
This is what LmcUser 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 LmcUser).
Third party authentication is becoming more and more popular. LmcUser 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 LmcUser 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 LmcUser 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 LmcUser's authentication system.
LmcUser 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
LmcUser 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 LmcUser were flexible enough the another module could provide a feature like this.
Going along with scenario 3, it would be cool if LmcUser could be used as the backend for a website which is an OpenID and/or OAuth provider for other applications.