Requirements

[WanWizard]

• The Auth framework is controlled by the Manager, every instance of the Manager works autonomous, and can have it's own configuration.
• The Manager supports three driver types:
  • user, for user authentication and information.
  • group, for group information and membership.
  • acl, for authorisation.
• At least one user driver is required, others are optional.
• You can use multiple drivers of any given type.
• A single driver can implement multiple types:
  • This will allow close integration between the different driver types, needed for some backends.
• Driver instances can be added, removed or accessed at runtime.
• For user authentication, two modes exist:
  • try all: attempt authentication using all defined drivers
  • first hit: stop as soon as a driver succesfully authenticates
• The user driver supports multiple groups in it's API. If the backend doesn't support groups, or only a single group, either an empty array or an array with one group is returned. The array will always contain "id => name".
• A local users table is used, to store unified user information, and to provide a unique user id to the application, independent of the authentication backend being used.
• A local groups table is used, to store unified group information, and to provide a unique group id to the application, independent of the authentication backend being used.
• A syntax for ACL definition will be proposed as a standard, and used by the supplied ACL drivers, but this will not be enforced, so devs can implement their own ACL system if needed.
• When calling methods, the Manager will distribute the calls to the correct driver:
  • when not logged in, it will call all drivers
  • when logged in, it will only call "logged-in" user drivers, it will call all other drivers

[WanWizard]

Earlier remarks wherre made here: fuel/auth#45

[phil-lavin]

SimpleAuth could well serve as a good example of basic but complete (user, group, acl) auth functionality. I suggest stripping it back until it's actually simple as it was very difficult to get into writing Auth drivers.

[WanWizard]

The problem with making a framework is that you have the challenge of catching both the simple and the complex cases, but keep the API design simple.

[sagikazarmark]

I am currently working on some kind of OTP authentication, this could also be a good feature. This is not really driver-dependent, so it could be implemented apart from any driver. Might be a bit crazy for a framework. 😄

[WanWizard]

OTP is mainly about the backend, issuing random one-time passwords, and have a login driver authenticate against that backend. Since in the Auth framework drivers are swappable, you can mix and match any login, group, acl (and possible role) driver.

[sagikazarmark]

OTP is mainly used in two-factor authentication nowadays, so this could be a driver-independent feature and any driver could use it. I imagine this as a layer between the logged in state and the first-step-authenticated state. So if the auth driver authenticated the user, it sends it to the OTP page, no matter what the driver is. Only, if two-factor auth is enabled and the user has configured it.

OTP shouldn't be a regular auth driver (IMO), as it is only a form of authentication, no groups and no ACL. But in practice it might be easier to implement it, but even if multiple login is allowed, it is hard to say, 'You have to authenticate against this driver as well'. So from this point of view, it is better to give better to implement OTP as something different from an auth driver.

I am saying all this with less experience in developing than using OTP, but we will see.

[WanWizard]

Ah, you meant on top of an existing authentication, instead of as a replacement of it?

I don't really see the point of that, other then that you see it a lot because people tend to "bolt it on" an existing auth solution in an attempt to be more secure. In general, an OTP is alreadly more secure then a fixed password, so if you have OTP, why still ask for the fixed one?

What I do see in professional OTP systems like for example RSA's secureID, is that they use a pincode, and you log in with username, and pincode + OTP token as password, in a single password field. The backend separates the two and validates them. SecureID can be plugged into all kinds of applications and OSses, including Windows. When done, Windows no longer uses your active directory password.

So I still think the best and most flexible design is to create an OTP login driver. No need to make it more complex.

[sagikazarmark]

Actually the way I would like to implement OTP could let people use two-factor authentication. I agree with that OTP is more secure in general. But nowadays in corporate systems OTP is used for two-factor authentication, and is a requirement. So you have to be in possession of your authentication data and a device (like secureID (I also used it, and it is a very good example), Google Authenticator etc), so even if your login data is compromised (Heartbleed bug!), your system is still protected.

So an OTP driver and two-factor authentication are two different things, and implementing an OTP driver is OK, but that does not make it two-factor. Or do you mean an auth driver, which implements this functionality (username&password+OTP)? In this case: it means that it can't be used with eg. Ormauth. So I imagine it like Opauth. It integrates into other auth drivers.

[WanWizard]

Most OTP systems work with "username + password(or pin) + OTP", yes, so two input fields, which are normally just called "Username" and "Password", the OTP stuff happens transparent for the user.

So basically you want a sort of "hook" into the Login driver system, or a multiple concurrent driver system, to which you can add an "authentication pre-treater" that gets passed the posted username and password, does it's thing, and either returns the username and password to the next in the chain (or the logiin driver itself) or signal a failure.

The basis of this already exists (you can define 3 login, 2 group and 1 ACL driver without problems, working concurrently), but now they all work on the initial data. And ideally you would want your OTP driver to go first, validate, and if valid, strip the OTP data from the password field, and return that so an (in your example) Ormauth login driver gets the username and plain password (without the OTP data).

[sagikazarmark]

@WanWizard Regarding this OTP stuff:
https://cartalyst.com/manual/sentinel#checkpoints

This is a sane description generally what I imagined.